home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d8
/
ra_100.arc
/
RA.DOC
< prev
next >
Wrap
Text File
|
1991-02-16
|
232KB
|
6,773 lines
┌─────────┐┌───────┐ ┌────────────┐┌──────────┬───────────┬───────┐
│ ┌───┐ ││ ┌───┘ │ ┌─┐ ┌─┐ ││ ┌───┐ ├────┐ ┌───┤ ┌───┘
│ │ │ ││ └───┐ │ │ │ │ │ ││ │ │ │ │ │ │ └───┐
│ └───┘ └┤ ┌───┘ │ │ │ │ │ └┤ │ │ └┐ │ └┐ │ ┌───┘
│ ┌────┐ │ └─────┤ │ │ │ │ │ └───┘ │ │ │ │ └─────┐
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │
└──┘ └──┴─────────┴──┘ └──┘ └───┴───────────┘ └───┘ └─────────┘
┌──────────┬──────┐ ┌──────┐ ┌───────┐ ┌───────┐ ┌───────┐
│ ┌───┐ │ ┌──┘ │ ┌──┘ │ ┌───┘ │ ┌───┘ │ ┌───┘
│ │ │ │ │ │ │ │ └───┐ │ └─────┤ └─────┐
│ └───┘ │ │ │ │ │ ┌───┘ └─────┐ ├─────┐ │
│ ┌────┐ │ └────┤ └────┤ └─────┬─────┘ ├─────┘ │
│ │ │ │ │ │ │ │ │
└──┘ └──┴────────┴────────┴─────────┴─────────┴─────────┘
RemoteAccess v1.00
(C) 1989-91
Andrew Milner and Continental Software, All Rights Reserved
TABLE OF CONTENTS
────────────────────────────────────────────────────────────
PREAMBLE AND CREDITS . . . . . . . . . . . . . . . . . 2
OVERVIEW AND FEATURES . . . . . . . . . . . . . . . . . 3
LICENSING INFORMATION . . . . . . . . . . . . . . . . . 5
HOW TO REGISTER . . . . . . . . . . . . . . . . . . . . 6
REGISTRATION FORM . . . . . . . . . . . . . . . . 8
The key system . . . . . . . . . . . . . . . . . . 9
PRODUCT SUPPORT . . . . . . . . . . . . . . . . . . . . 10
AUSTRALIA . . . . . . . . . . . . . . . . . . . . 10
USA and CANADA . . . . . . . . . . . . . . . . . . 10
EUROPE . . . . . . . . . . . . . . . . . . . . . . 11
INSTALLATION . . . . . . . . . . . . . . . . . . . . . 12
CONFIGURATION . . . . . . . . . . . . . . . . . . . . . 13
QuickBBS to RemoteAccess . . . . . . . . . . . . . 13
RACONFIG . . . . . . . . . . . . . . . . . . . . . 14
Modem . . . . . . . . . . . . . . . . . . . . 14
Other (miscellaneous) . . . . . . . . . . . . 17
Events . . . . . . . . . . . . . . . . . . . 23
Files . . . . . . . . . . . . . . . . . . . . 24
Messages . . . . . . . . . . . . . . . . . . 29
SECURITY . . . . . . . . . . . . . . . . . . . . . . . 33
MENUS . . . . . . . . . . . . . . . . . . . . . . . . . 34
Menu functions . . . . . . . . . . . . . . . . . . 35
Automatic command execution . . . . . . . . . . . 59
Special optional data switches . . . . . . . . . . 59
Menu templates . . . . . . . . . . . . . . . . . . 60
The global menu . . . . . . . . . . . . . . . . . 61
Setting up your menus . . . . . . . . . . . . . . 62
Creating your menus - RAMENU . . . . . . . . . . . 63
EXTERNAL SUPPORT FILES . . . . . . . . . . . . . . . . 65
BADFILES.CTL . . . . . . . . . . . . . . . . . . . 68
FILES.CTL . . . . . . . . . . . . . . . . . . . . 68
LIMITS.CTL . . . . . . . . . . . . . . . . . . . . 69
NAMES.RA . . . . . . . . . . . . . . . . . . . . . 70
PHONENUM.CTL . . . . . . . . . . . . . . . . . . . 70
PWDTRASH.CTL . . . . . . . . . . . . . . . . . . . 71
TRASHCAN.CTL . . . . . . . . . . . . . . . . . . . 71
THE USER DATABASE . . . . . . . . . . . . . . . . . . . 72
Information stored in the user database . . . . . 73
Packing and sorting the user file . . . . . . . . 74
THE MESSAGE DATABASE . . . . . . . . . . . . . . . . . 75
Message database size limitations . . . . . . . . 75
RAMSG Command summary . . . . . . . . . . . . . . 76
MAIL NETWORKING . . . . . . . . . . . . . . . . . . . . 80
Installing the nodelist files . . . . . . . . . . 83
MULTI - NODE OPERATION . . . . . . . . . . . . . . . . 85
REFERENCE SECTION . . . . . . . . . . . . . . . . . . . 88
Sysop keys . . . . . . . . . . . . . . . . . . . . 88
Command-line parameters . . . . . . . . . . . . . 90
Errorlevels . . . . . . . . . . . . . . . . . . . 92
Text file control codes . . . . . . . . . . . . . 93
User Parameter Codes . . . . . . . . . . . . 95
System Parameter Codes . . . . . . . . . . . 96
Modem string translation . . . . . . . . . . . . . 97
Questionnaire script language . . . . . . . . . . 98
Terminal emulations . . . . . . . . . . . . . . 103
Text file naming conventions . . . . . . . . . . 104
Interactive EMSI . . . . . . . . . . . . . . . . 105
BATCH FILE EXAMPLES . . . . . . . . . . . . . . . . . 106
RemoteAccess stand-alone . . . . . . . . . . . . 106
RemoteAccess with a mailer . . . . . . . . . . . 107
The following products and names are the copyrighted
material and or trademarks of their copyright and or
trademark holders respectively:
QuickBBS,
Echogen & QEcho The QuickBBS Group, Inc.
DESQview Quarterdeck Systems
DoubleDOS SoftLogic Systems
TradeWars Chris Sherrick
Opus Wynn Wagner III
TosScan & FrontDoor Joaquim H. Homrighausen
BinkleyTerm Bit Bucket Software
ZmailH Claude N. Warren
FidoNet Tom Jennings
IBM International Business Machines
ParaNet ParaNet Information Systems
MS-DOS Microsoft Corporation
X00 Ray Gwinn
BNU David Nugent
Turbo Pascal Borland International
TinyTerm Adam Stanislav
1
PREAMBLE AND CREDITS
────────────────────────────────────────────────────────────
Firstly, let me say that RemoteAccess was very much a team
effort. I had been running my bulletin board for about a
year, it was getting pretty busy so I put on a second line.
The software I was using was QuickBBS, so I did a heap of
work trying to get it running both lines. For the most part
it worked, but it was very clumsy. I was complaining to Bob
Fletcher, a sysop in Victoria, about it one night, and Bob
said something like "Well, YOU could always have a go at
something better!" So the basic concept was born. An "all-
singing, all-dancing" BBS package that would run multiple
lines and occupy as little memory as possible. "Piece of
cake!" I thought. In my spare time I started playing around
with a couple of file-displaying utilities written in Turbo
Pascal 5 (which I had just bought, and was anxious to
learn.)
Enter Phil. Someone mentioned that "some bloke called Phil
Mackay" was writing a toolbox of routines to manipulate the
QuickBBS message and user database files so I dropped him a
message. Phil was immediately taken by the idea and sent me
the source to what he had written. I was impressed. As it
happened, Bob was in Perth at this time and during a couple
of brainstorming sessions helped to refine what I already
had (which wasn't much).
Gradually I started to spend more and more of my spare time
working on it, and I started to realise the scale of the
project (which still kinda frightens me). I realised there
was no way I could do it all myself, so I enlisted the help
of one or two other people to write utilities, and "farmed
out" a fair bit of coding to Phil. All the following people
deserve recognition for their contributions:
Phil Mackay - all the high and low-level message database
routines, the menu editor and an infinite number of
suggestions, not to mention invaluable advice on many
occasions.
David Nugent - Wrote the message-base maintenance utility
"RAMSG", was ALWAYS ready to provide answers to any low-
level communications problem, and wrote the multitasker-
aware code.
Adam Blake - Did the configuration utility "RACONFIG" and
changed it twice a day when I made more mods to the main
program, uncomplainingly. (Well, almost).
The beta test team - thanks guys! Couldn't have done it
without ya. Too numerous to list here, all the current beta
systems are listed in the accompanying document RA-
BETAS.DOC.
Andrew Milner.
Perth, Western Australia.
─────────────────────────
2
OVERVIEW AND FEATURES
────────────────────────────────────────────────────────────
RemoteAccess is a "fully-blown" remote bulletin board
package. It may be used as a stand-alone system or with a
front-end mailer if you wish to interface it to a mail
network such as FidoNet. It offers fully definable menus
with a unique template system which provides not only a
massive degree of flexibility in making your BBS look
different from any other, but also the lowest possible
maintenance. AVATAR screen control is built in, making
possible extremely efficient and complex colour and cursor
control at the user's end if an AVATAR terminal program is
used.
Access to the 200 available message areas is controlled by
your menu structure, along with a sophisticated security
system which incorporates over 64,000 security levels with a
set of user-definable flags. For each security level you can
specify maximum download limits for different log-on speeds,
daily time limits, and optionally activate the built-in file
ratio system, limiting downloads by ratio to uploads by
either number of files or kilobytes. In addition it's
possible to assign a user to one of 255 separate groups, and
in so doing segregate groups of users from each other.
Other security features include the disallowing of downloads
during peak hours, disallowing low speed callers at certain
times, and disallowing ANSI graphics at low speeds. You can
disallow one-word "pseudonyms", and optionally configure
the system to force a user to change passwords every x log-
ons. Undesirable user names and passwords are also definable
for maximum security. If you're unlikely to want to call
your own system, remote sysop access can be disabled, making
it virtually impossible for your account to be "hacked".
Direct support for high-speed modems up to 38,400 baud is
available, and RemoteAccess will optionally answer the phone
automatically to ensure that the modem will answer if your
BBS is "alive and well".
RemoteAccess supports as many as 99 lines simultaneously.
Full system access to all file and message areas is
available to each line (at your discretion), as are all
doors. Several "multi-node specific" features are provided
to augment multi-line operation. You can configure the
system to disallow one person logging on to more than one
line at a time. A "who else is on-line?" and "today's
callers" function is available to you, along with separate
system logs for each line. Logging is selectable between
either Opus or FrontDoor styles to aid integrated log
readability. Some basic user-to-user on-line messaging,
to be expanded at a later date, is also available.
3
RemoteAccess does NOT do its own internal multi-tasking. To
this end, we have attempted to make it as well-behaved as
possible. It has built-in time-slicing and screen-handling
support for DESQview, TopView, MultiLink, DoubleDOS and
PC-MOS/386. It is fully overlaid and occupies approximately
190k of memory when fired up. What do you do if you have say
a 300k DESQview window and want to run TradeWars in a shell?
No problem! Simply by specifying a control character on the
command line, you can instruct RemoteAccess to swap itself
lock, stock and barrel to EMS and/or disk leaving only 20k
resident.
A comprehensive file transfer system is also part of the
package. Six of the most popular protocols, including
Zmodem, Ymodem batch and Xmodem are built-in, and fifteen
slots for external protocols are available for you to add
any others. All protocols may be made available on an
"error free" connect basis at the your discretion. The
protocol interface system is extremely flexible, and
has been tested with DSZ, Kermit (an Opus compatible
protocol), and BiModem. There are of course many others we
haven't tested, but most should work. Support for CD-ROM and
other mass read-only media is another invaluable feature.
The file transfer system is further enhanced by
comprehensive file search and locate functions along with
the ability to tag any file or group of files as "free" and
or password protected. A large selection of transfer options
include global downloads and the ability for specific files
to be attached to a file transfer menu option.
Interactive EMSI session support is an exciting new first
for RemoteAccess! Read the section on IEMSI in the reference
section at the end of this document for details on this
revolutionary new set of features.
Extensive on-line facilities are available to the sysop. An
optional set of status bars provide a wealth of information
about both the person currently on-line and the system.
Several "hot-keys" are also available to perform a wide
range of functions, amongst which is a full screen user
attribute editor, a "sysop on next" key, shell to DOS, hang
up, lock out, and local snoop.
As an added bonus, we have decided to use the QuickBBS-style
user and message database formats. This means that you can
continue to use your favourite QuickBBS utilities with no
need to convert to another format. Any incompatibilities in
the configuration files is taken care of by an upgrade
utility. We make no apology for the similarity between
RemoteAccess and QuickBBS. QuickBBS had many features that
we wanted, and compatibility gives the added bonus of
offering the sysop ease of installation and a familiar
environment.
To cater for both Opus and QuickBBS users alike, each user
has (at the discretion of the sysop) the option of using
hot-keyed menus or command stacking. Comprehensive
messaging, file search options and support for a wide range
of "doors" ensure that your BBS will be a hit!
4
LICENSING INFORMATION
────────────────────────────────────────────────────────────
"RA" refers to the executable programs and documentation
contained in RemoteAccess Bulletin Board Software
distribution archives released by Continental Software.
1. RA is the copyrighted material of Continental Software.
It may only be used in accordance with the conditions set
out in this license agreement.
2. You may use RA for a period of three weeks on a trial
basis in order to determine it's suitability for your
particular application. After this period you MUST register
each copy of RA that you run simultaneously. Multi-line
installations that share a common file base AND have the
same name need only register one copy.
3. Registration entitles you to use RA and any future
versions of RA for as long as you wish, subject to any
special licensing conditions attached to future versions.
For details on the registration procedure, refer to the
section in this document "HOW TO REGISTER".
4. Continental Software is in no way obligated to
provide future versions of, or support for, RA.
5. Site and Group registrations are available, and are dealt
with on a case by case basis.
6. You may not modify or otherwise reverse-engineer RA.
7. You are encouraged to distribute RA provided that no fee
is charged for its distribution, and that the distribution
archive is not modified in any way. Pay Bulletin Board
Systems may however charge their normal fee provided that
no additional charge for RA is levied.
8. RA may not be included as part of any software library
which is distributed on a commercial basis (commercial =
"for money") without prior written permission from
Continental Software.
9. RA may not be used in any unlawful or illegal manner.
10. Continental Software's liability resulting from your
use or inability to use RemoteAccess is limited to the
amount that the affected party has paid for it, or in the
event that RA was registered with a third party for payment
to Continental Software, liability is limited to the amount
that was received by Continental Software from that third
party.
5
HOW TO REGISTER
────────────────────────────────────────────────────────────
Print or reproduce the registration form at the end of this
section and send it with your registration payment to one of
the following sites:
AUSTRALIA:
"Registration/RA" "Registration/RA"
Continental Software Box 10
C/- Milner Intl College 312b North Rocks Rd
195 Adelaide Terrace North Rocks 2151
Perth 6000 NSW AUSTRALIA
WESTERN AUSTRALIA
EUROPE: USA:
"Registration/RA" "Registration/RA"
C/- R.A. de Bruin C/- Ed Meloan
Columbusrede 17 1110 Terrace Circle Drive
2725 KL Zoetermeer North Augusta SC 29841
HOLLAND
CANADA:
"Registration/RA"
C/- Royce Jones
624 Dolph Street N. Apt. #B
Cambridge ON
CANADA N3H-2B4
NOTES:
* You MUST fill out the registration form correctly in order
for your details to be processed. Not doing so will result
in delays in your key arriving.
* Cheques and money orders should be made payable
to Continental Software UNLESS you are registering in the
USA, Canada or Europe. USA residents should make cheques
payable to Ed Meloan; Canadian cheques should be made
payable to Royce Jones, and cheques sent to the European
registration site should be made payable to R.A. de Bruin.
* Please include either a FidoNet address or a stamped,
self-addressed envelope so that receipt of your payment
can be acknowledged.
6
* All COMMERCIAL U.S. enquiries should be made to:
Richard Brannon
PowerNet
625 Greencove Terrace
#128 Altamonte Springs
FLORIDA 32714
(407) 788 3736
REGISTRATION FEES: Simply use the denomination that is
accepted by the registration site which
covers your area.
Noncommercial : $AUD60, $US50, $CDN60, DFL120
Systems that qualify for this category must be
physically run from a noncommercial site. A site is
considered to be noncommercial only if it is a private
residence at which no commercial activities are
conducted.
Commercial/1 : $AUD150, $US120, $CDN150, DFL280
If the system is physically run from a commercial site
(ie. the site is not a private residence, or commercial
activities are conducted at the site), but does not
generate revenue as part of the PRIMARY commercial
activities conducted at that site.
Commercial/2 : $AUD350, $US265, $CDN350, DFL625
If the system generates revenue as part of the
primary commercial activities conducted at the system
site.
7
*** RemoteAccess REGISTRATION FORM ***
Sysop Name _________________________________________________
System Name ________________________________________________
[The above two items are used to generate your registration
key and must appear EXACTLY as they do in RACONFIG.]
Network Address (number and network name) __________________
Any other networks you are a member of _____________________
Primary BBS telephone number and baud ______________________
Voice telephone number _____________________________________
Hours of BBS operation _____________________________________
Postal Address :
____________________________________________________________
____________________________________________________________
____________________________________________________________
Version of RemoteAccess registering ______.
Registration amount enclosed _______, for ____ copies.
What do you like about RemoteAccess?
____________________________________________________________
____________________________________________________________
____________________________________________________________
What enhancements/changes would you like to see in our next
release?
____________________________________________________________
____________________________________________________________
8
The key system
────────────────────────────────────────────────────────────
Upon registering you will receive your uniquely generated
key. Each key is a small file approximately 2k in size which
contains information about your registration. To install the
key, simply rename it (if necessary) to RA.KEY and copy it
to your RemoteAccess system directory.
When RemoteAccess detects a valid key it switches into
registered mode, identifying itself by placing a "+" at the
end of the version number as well as displaying the name of
the system and sysop it is registered to in the "version
information" menu function.
For example, logging on to a registered system you would
see:
RemoteAccess 1.00+
Please enter your full name:
Features marked in this manual with a {+} are only available
when RemoteAccess is running in registered mode. These bonus
features show our appreciation of your taking the time to
register with us.
It should be made absolutely clear that RemoteAccess is
still fully functional before it is registered; the bonus
features are "nice" but their absence makes the system no
less usable. RemoteAccess is not and never will be
"DemoWare" or "ExpireWare".
WARNING! Your key is unique, and under NO circumstances
should it be made available to anyone else. Doing so is a
direct violation of the agreement you entered into with us
by registering.
9
PRODUCT SUPPORT
────────────────────────────────────────────────────────────
You can always get the latest version of RemoteAccess and
technical support from the following systems:
AUSTRALIA:
Andrew Milner Phil Mackay
RemoteAccess HQ RemoteAccess HQ East
Perth WA Sydney NSW
+61 9 389 8048 V32/HST +61 2 872 6159
FidoNet@3:690/625 FidoNet@3:711/801
USA and CANADA: (North American RemoteAccess Support group)
Bruce Bodger Fred Horner
The TruckStop BBS The Private EaR
Tulsa OK Waco TX
918 254 6618 HST 817 776 9877 HST
FidoNet@1:170/400 FidoNet@1:388/10
Mike Janke Ed Meloan
Kendall BBS Augusta Forum
Miami FL N. Augusta SC
305 271 2146 HST 803 279 4124 HST
FidoNet@1:134/104 FidoNet@1:360/1
Al Bruner Royce Jones
The SW/SE Connection DAKIN BBS
San Diego CA Cambridge Ontario
619 467 0335 HST 519 653 7677 HST
FidoNet@1:202/707 FidoNet@1:221/204
Mark Howard Jamie Penner
Rivendell SIGnet Netlink
Syracuse NY Burnaby BC
315 458 8602 HST 604 421 1721 HST
FidoNet@1:260/340 FidoNet@1:153/169
Jim Roe
Middle Earth
Austin TX
512 835 4848 HST
FidoNet@1:382/19
10
EUROPE:
John Barton Malte Erikson
European Support Coordinator SWEDEN
UNITED KINGDOM +46 300 29436
+44 708 670068 HST FidoNet@2:203/302
FidoNet@2:257/168
Ruud de Bruin Stefano Pasquino
HOLLAND ITALY
+31 79 424553 V32 +39 766 540899
FidoNet@2:281/603 FidoNet@2:335/5
Joerg Dassler Benoit De.Guffroy
GERMANY BELGIUM
+49 9132 9145 HST +32 51 241352
FidoNet@2:509/6 FidoNet@2:285/56
Robert Maierhofer Hilmar Thors
AUSTRIA ICELAND
+43 1 390545 +354 1 77568
FidoNet@2:310/19 FidoNet@2:257/3000
Lars Erikssons Kalin Krustanov
FINLAND BULGARIA
+35 828 23452 +359 2 8672082
FidoNet@2:515/450 FidoNet@2:359/103
Robert Sorbie
FRANCE
+33 568 95112
FidoNet@2:324/1
There is also an echomail support conference available,
called RA_SUPPORT to answer all of your questions.
New releases and the RA_SUPPORT conference should also be
available from any of the beta test sites, listed in the
accompanying document RA-BETAS.DOC.
11
INSTALLATION
────────────────────────────────────────────────────────────
RemoteAccess should run on any IBM 80x86 compatible
computer. The only two programs you will need in addition to
the release package are DOS 3.x and a FOSSIL driver. The
FOSSIL is a memory-resident program that many communications
packages use to communicate with the modem. Two FOSSILs that
have been successfully tested with RemoteAccess are Ray
Gwinn's X00, and David Nugent's BNU. Either of these should
be readily available from any local bulletin board.
You will also need a modem that is capable of accepting
Hayes-type commands. The minimum memory requirement is
approximately 190K, but 512K is recommended.
1. Ensure that your CONFIG.SYS file contains these
statements:
FILES=20
BUFFERS=25
The more buffers you allocate, the faster
RemoteAccess will run. However, more buffers use
more memory.
2. Create a directory to put the main program files
in. The configuration example that follows later
assumes that this directory (the SYSTEM directory)
is C:\RA.
3. Ensure that your AUTOEXEC.BAT file contains a
command to set the environment variable RA to your
SYSTEM directory, so RemoteAccess can find its
configuration files:
SET RA=C:\RA
4. Copy all of the executable files from the
RemoteAccess distribution package into this
directory.
5. Create three more sub-directories:
C:\RA\MSGBASE This will hold the message
files the system creates.
C:\RA\MENUS To put your menus in,
C:\RA\TXTFILES To put files such as welcome
and disconnect screens in.
You are now ready to proceed to the next step,
CONFIGURATION.
12
CONFIGURATION
────────────────────────────────────────────────────────────
If you are upgrading your system from a presently-existing
QuickBBS system, then read the next paragraph. If you're
installing RemoteAccess from scratch then skip to the
section on RACONFIG.
QuickBBS to RemoteAccess
────────────────────────────────────────────────────────────
A utility, called QTORA.EXE has been provided to allow you
to convert your existing QuickBBS configuration files to the
RemoteAccess format. Note that it will not modify your
existing configuration files in any way. Copy QTORA to your
QuickBBS system directory and run it. It will prompt you
through the whole conversion process, and when it has
finished, copy all the files it has created to your
RemoteAccess system directory:
COPY *.RA C:\RA
Now, copy all the *.CTL files to your RemoteAccess system
directory:
COPY *.CTL \RA
The final step is to copy all of your BBS system files to
the RemoteAccess directories. Copy all the message files
(MSG*.BBS) and the user files (USERS.BBS and LASTREAD.BBS)
to the message base directory, and all the other *.BBS files
to the system directory.
The conversion process is now complete, and you can delete
QTORA.EXE, as it will not be needed for anything else.
13
RACONFIG
────────────────────────────────────────────────────────────
Return to the RemoteAccess system directory again, and fire
up the configuration utility, RACONFIG.EXE. You will use
this to choose the configuration options for your particular
system. You will see that there are six options in the menu
bar. Here is a walk-through of the various options.
Modem
────────────────────────────────────────────────────────────
Select the MODEM option, and then SETUP. This window
contains general configuration information for your modem.
The first item is the COMPORT setting. Set this to the
communications port you have your modem hooked up to. Valid
ports are 1-4. MAXIMUM BAUD refers to the highest modem-
computer speed your modem supports. If you are using a high-
speed modem you should lock the speed at the modem's maximum
speed to ensure the highest possible throughput. Refer to
your FOSSIL documentation on how to do this.
The INITIALISATION RESPONSE is the string that the modem
returns after RemoteAccess sends it the initialisation
string. Most modems return "OK". Likewise for the BUSY
RESPONSE, most modems also return "OK". Check your modem
operating manual for more information.
The RING STRING is the string the modem displays when
someone calls your system, to indicate that the call should
be answered. Most modems return "RING", some use "RINGING".
Check your modem manual and set this accordingly.
ERROR FREE CONNECT is the response your modem returns when
it gets an MNP connection. Ignore this entry if your modem
doesn't support MNP. Check your modem manual to determine
what string your modem returns.
CONNECT 300 - CONNECT 38k are the response strings the modem
returns when a connection is made with another modem. Most
modems return a "CONNECT <Baudrate>" string, or simply
"CONNECT" for 300 baud. Note that if this is the case you
should specify the vertical bar after the string to indicate
the end of the string. (See MODEM STRING TRANSLATION in the
reference guide at the end of this document).
AUTOMATIC ANSWER. Setting this to "Yes" tells RemoteAccess
to make the modem answer the phone whenever it receives the
ring string by sending the answer command to the modem (see
INITIALISATION). If it is set to "No" then it is assumed
that the modem will answer the phone itself. "Yes" is the
preferred setting, as it ensures that your BBS will only
answer the phone if it is "alive and well". Otherwise, you
are likely to upset your users when they waste their money
on a BBS that answers the phone and then does nothing.
14
MODEM DELAY refers to a delay, in tenths of a second that
RemoteAccess waits between sending characters to the modem
during initialisation. Usually you will only need to raise
this above zero if you are using a high-speed modem that
cannot handle commands at high speeds. A typical example of
this is the Courier HST, which requires a delay of about 3.
The OUTBOUND BUFFER SIZE field sets the size of
RemoteAccess' internal communications send buffer for baud
rates up to 2400. You can change it to fine-tune your system
for maximum throughput. If you are using a slow machine (ie.
a 4.77 MHz XT), set it to zero. This disables the internal
buffering system and its associated overhead. For most
systems, the default setting of 5 will not need to be
changed. In a multi-tasking environment though, you will
achieve much better performance by increasing the buffer
size. Experimentation has shown values around 80-150 to be
most effective.
Some modems (such as the Courier HST) can be configured to
clear their internal transmit buffer when they receive a
break signal from the local console. If the SEND BREAK TO
CLEAR option is enabled, RemoteAccess will send a break
whenever it purges it's own internal transmit buffer. The
result will be a faster hotkey response.
Now select the INITIALISATION submenu. INITIALISATION TRIES
is the number of times RemoteAccess will attempt to
initialise the modem before aborting and returning an error
condition.
The INITIALISATION STRING is sent to the modem whenever
RemoteAccess is fired up. This string should prepare the
modem to take calls. See the reference section MODEM STRING
TRANSLATION at the end of this document for more
information.
The BUSY STRING is sent to the modem whenever you either
log-on locally or if you ESCape from the "wait for call"
sequence. You could either tell the modem to go "off hook"
with an "ATH1|", or simply not to answer the phone by
dropping DTR.
The ANSWER STRING is sent to the modem if you have set
automatic answer on, and a call comes in. Most modems will
answer a call upon receiving an "ATA|" from the computer.
Next select the ERRORLEVELS submenu. These values are used
if you have activated the "Shell to Mailer" feature.
For full information on this option, read the reference
section on COMMAND LINE PARAMETERS.
15
Select the RESTRICTIONS submenu. MINIMUM BAUD FOR LOGON
allows you to set the lowest baud rate for a user to log on
to your system. Calls at 300 baud may be restricted by using
the NO 300 START and NO 300 END options. To disable this
option, set both start and end times to 00:00.
You can also limit file downloads in the same way. However,
this option differs slightly in that the MINIMUM BAUD FOR
FILE TRANSFERS applies all the time. The DOWNLOAD START/END
times specify times during which downloads may occur. Note
that this time restriction may be cancelled for certain
users by setting a flag in their user record. See the
section on USERS for more on this.
16
Other (miscellaneous)
────────────────────────────────────────────────────────────
Select the PATHS menu. Here you tell RemoteAccess where
all its associated files are stored. The directories are
the same as the ones discussed earlier in the installation
example. Enter the full directory paths to your chosen
directories. The trailing backslash is optional.
See the section on MAIL NETWORKING for details on how to set
up the NODELIST path. Check the section on message
configuration for details on the FILE ATTACH PATH, and the
section on files configuration for details on the FILE LIST
path.
Select the ADDRESS submenu. If you do not intend to use
your BBS in a mail network (eg. FidoNet, AlterNet) then skip
this section. Select MAIN ADDRESS and enter your network
address. If you have any alias addresses (AKAs), enter these
in one or more of the nine slots provided. For extra
information on network operation and an explanation of
addresses, see the section on MAIL NETWORKING.
Now select the NEW USERS submenu. SECURITY is the
security level (0 to 64,000) that will be granted to a new
user who logs on for the first time. If you run a
private system, and do not want to allow new users to log
on, set this field to zero. In this case, the user is
notified that the system is private and is disconnected.
The four flag entries determine the flag configuration that
will be granted to new users. See the section on SECURITY
for a full description of the RemoteAccess security system.
NETMAIL CREDIT is the new user's initial credit against
sending netmail messages. The NETWORKING section provides
full details on setting up netmail costings.
GROUP NUMBER is an arbitrary number between zero and 255 you
may assign new users. It allows you to segregate users into
separate groups. Presently the only support for the group
number exists in the list users menu command (see the menu
command list for further details).
The next four entries, ANSI, AVATAR, CLEAR SCREEN and MORE
determine how these attributes are set in the user's
permanent record. Set to "No" will force the option off;
"Yes" forces the option on, and "Ask" asks the new user for
his/her preference for each setting.
The next two options determine whether new users will be
asked for their data and voice telephone numbers. The
numbers are checked against a definable list of "bad"
numbers. The EXTERNAL SUPPORT FILES section has more on the
PHONENUM.CTL file.
17
If ALLOW ONE WORD NAMES is disabled, new users will be
required to enter their name as at least two words with a
total length of at least three characters. Note that this
restriction only applies to new users; a user already in the
user database may log on using his or "handle".
If the HANDLE option is enabled, new users will be asked to
choose a an optional unique handle, or alias. THis is saved
as part of the user's record and may be used to log onto the
system later, and to send and receive mail. More details on
this are in the messages configuration section.
If DATE OF BIRTH is enabled, new users will be prompted to
enter their full birthdate. RemoteAccess will attempt to
"intelligently" identify if the date supplied is legitimate.
RemoteAccess may be configured to behave either like
QuickBBS with hot-keyed menus, or like Opus with command
stacking facilities. If the USE HOT-KEYS option is set to
"Yes", the system defaults to hot keys for each new user. If
the option is set to "Ask" then each new user is asked to
choose between hot keys or command stacking. The user may
change his or her choice by selecting the toggle hotkey menu
command (see the section on MENU FUNCTIONS).
The FULL SCREEN MSG VIEWER, when enabled, will display
messages to the user using an improved "fixed header"
format, designed for enhanced readability.
The final option on the new users submenu is ALLOW IEMSI
SESSIONS. When a new user connects to your system using
IEMSI (explained fully in the reference section of this
manual), RemoteAccess will skip the regular new user
questionnaire as it can determine the user's screen
parameters, location, password etc. automatically. If this
option is disabled however, all new users will be forced to
answer the regular questionnaire manually.
The COLOURS submenu allows you to costomise some of the
more-often used colours that the user sees.
Now go to the VIDEO submenu. You can force the system to run
in Monochrome Mode by setting MONOCHROME to "Yes". If you
are not using RemoteAccess in a multi-tasking environment,
then set DIRECT WRITE MODE to "Yes". This will cause all
screen output to be written directly to Video RAM instead
of using BIOS calls, and will result in a significant speed
increase. If you use one of the older CGA cards that is
prone to "snowing", set SNOW CHECK to "Yes".
18
Select the USERS submenu.
NUMBER OF TIMES TO TRY FOR PASSWORD sets the maximum number
of invalid password attempts. After this is exceeded the
user will be disconnected.
LOGONS BEFORE FORCED PASSWORD CHANGE is another security
feature. If this is set to any non-zero value, then all
users (excluding the sysop) will be forced to change their
password every number of logons as determined by its value.
TIME LIMIT FOR LOG-ON PERIOD specifies how much time to
grant to a user before the system knows how much time he/she
is entitled to. You should make this long enough to enable a
new user to complete the new user procedure and
questionnaire, if you have one.
MAXIMUM USER INACTIVITY PERIOD determines how long to wait
during periods of inactivity before disconnecting. The
inactive time period is measured from the last character
sent to the modem, and users are given a warning that they
are about to be disconnected fifteen seconds before the
timer expires. This feature is automatically disabled in
local mode, or by a setting of zero.
ALLOW USERS TO UPLOAD MESSAGES. When this option is set
to "Yes", when users enter a message they are asked if they
wish to "upload a prepared message?" This allows the user to
prepare his/her messages offline and send them using any of
the available file transfer protocols. Note that ONLY
internal protocols may be used as RemoteAccess does not have
enough control over the external ones. The maximum size of a
message that may be uploaded is pre-set at 20k.
The KILL MESSAGES AFTER SENT option applies to NetMail sent
through a mail network. When the message is entered, if set
to "Ask", it will ask the user whether to delete his/her
message after it has been exported from the message
database.
STRICT PASSWORD CHECKING is an invaluable security feature
which if enabled, will check passwords that users enter. You
can specify certain undesirable passwords in a control file
(see the section on EXTERNAL FILES), such as "Secret" or
"Test". It will also disallow the user's first or last name
as a password, and checks the old and new passwords for
phonetic similarity.
You may also specify the minimum password length that users
may select. Longer passwords mean better security, a value
of 4 is recommended as an absolute minimum.
19
If a user logs on and is disconnected because he/she enters
his or her password incorrectly, RemoteAccess can notify
that user of a possible attempt at guessing the password, by
way of a private message. In the SECURITY WATCHDOG MESSAGE
AREA field, specify the message area number (as per your
message area configuration) that the warning message should
be placed in. A value of zero disables this feature. In
addition, you will need to create an ASCII text file called
WATCHDOG.MSG in the system directory that contains the text
of the message that is sent to the user.
If ALLOW NETMAIL REPLIES TO ECHOMAIL is enabled, when
replying to an EchoMail message, users will be asked if they
would like to reply directly to the originator of the
message via netmail, rather than replying in the same area
with a message that might not be of interest to the other
participants. Note that this {+} registered only option is
only enabled if RemoteAccess can determine where the
original message came from.
If a user is disconnected due to exceeding the incorrect
number of password tries, you may give him/her the option of
sending a message to the sysop by setting the PWD FAILURE
MSG AREA to the number of the message area you would like
the message to be posted in. A value of zero disables this
feature. {+} Registered only.
If ASK FOR MESSAGE DELETE CONFIRMATION is enabled, users
will be asked for confirmation every time they elect to
delete a message from the message reading prompt.
Select the PAGING menu. PAGE LENGTH specifies the number
of seconds to sound the bell at the local console when a
user pages you for a chat. MAXIMUM PAGES allows you to
limit the number of times a user may page you during one
session. You may also specify paging "hours" using the
PAGING START/END TIME option. If either field is set to a
non-zero value, users will only be allowed to page you
between these hours.
If ASK FOR PAGE REASON is enabled, RemoteAccess will display
a custom prompt (see the SYSTEM MESSAGES submenu) and ask
the user why he/she wants to chat. The response is displayed
on the status bar, and may be redisplayed later by pressing
F6. {+} Registered only.
If the page was unsuccessful, the user will be prompted
whether to leave a message addressed to the sysop. This
option is enabled by setting the AREA FOR MSGS TO SYSOP to
the desired message area number, or disabled with a value of
zero. {+} Registered only.
The MESSAGES submenu allows you to customise a number of the
most commonly used "built in" display and prompt messages.
20
The SYSTEM submenu contains options that pertain to the
hardware/software environment plus some other global
options.
If you set ALLOW FAST LOGONS to "Yes", then whenever
RemoteAccess is activated in local mode, it will assume that
it is the sysop who is logging on, and will prompt for
password only.
If you are running more than one line, you should set CHECK
FOR MULTI-LOGON to "Yes". This will prevent a user from
logging on to more than one line at the same time, and
effectively using his/her entire daily time limit on EACH
LINE.
If you never (or rarely) call your own BBS remotely, you
should disallow sysop remote access by setting ALLOW SYSOP
REMOTELY to "No". This makes it almost impossible for an
unknown "hacker" to gain access to your system via your own
account.
EXCLUDE SYSOP FROM LIST, if set to "Yes", will cause the
sysops name to be ommitted from a User List, List of Today's
Callers, Who Else Is Online, and the Last Caller functions.
By inserting a special control code in a text file it is
possible to automatically activate a program in a shell when
the text file is displayed. As explained in the TEXT FILE
CONTROL CODES section, there are important security
considerations that must be looked into if you intend to use
this feature. If you aren't going to use it, set SHELLS FROM
TEXT FILES to "No".
The next option in the SYSTEM menu is the SYSTEM LOG FILE
NAME. RemoteAccess logs all user activity in detail to a
human-readable text file. {+} When running in registered
mode, RemoteAccess logs additional information about message
and file area activity.Set the name of the log file to
point to your system directory, for example C:\RA\RA.LOG.
Next, select the logging format that most suits you; Opus
mode contains more information, including the line number in
a multi-line system. The FrontDoor format is much more
compact.
If you are installing RemoteAccess on a multi-line site (ie.
you are going to be running more than one line), you MUST
set the MULTI LINE option to "Yes". This enables extra
file/message checking routines to ensure that a conflict
between two lines accessing the same data never arises. If
you are running only one line, setting this option to "Off"
will disable this checking and significantly increases the
system's operating speed.
21
The ENVIRONMENT option refers to the type of multi-tasking
system that you will be running RemoteAccess under. If set
to "Auto-detect", RemoteAccess will attempt to determine the
multitasker in use when it fires up. On some
hardware/software configurations it may not be able to
correctly detect it's environment. To overcome this, you can
force RemoteAccess to "assume" that it is running under a
specific multitasker. Environments currently supported are
DoubleDOS, DESQview, TopView, MultiLink, PC-MOS/386 and the
"standard" AT BIOS. RemoteAccess will time-slice, or give up
CPU time, to other tasks when it is waiting for a call or at
a prompt. The result is a significant overall system
performance improvement.
To avoid screen "burn in" on the "waiting for call" display,
set the SCREEN BLANKER to the number of seconds you would
like the display to remain visible after the last activity.
This is a {+} registered only option.
After RemoteAccess displays a system message, the default
action is to wait for one second before returning to the
current menu. You may alter this wait period by setting the
AFTER SYSTEM MESSAGES option to the desired number of
seconds. There is one special exception; if you set this
field to zero, instead of waiting for a few seconds,
RemoteAccess will prompt the user to press the Enter key to
continue.
The INTERACTIVE EMSI option simply allows you to enable or
disable RemoteAccess' IEMSI capabilities. IEMSI is fully
explained in the reference section at the end of this
manual.
The last option in the OTHER menu is ALT-FKEYS. When one
of the ten function keys on your keyboard is pressed
in conjunction with the ALT key, RemoteAccess will do one
of three things : If the command string that you have
assigned to the function key that is pressed is a standard
DOS command line, then that line will be executed in a
shell while RemoteAccess remains in memory. If, on the
other hand, the first character of the command string for
the function key is the query symbol (?) followed by a
number, RemoteAccess will exit to DOS with an errorlevel
equal to the number. Alternatively, if the first character
of the command string is the hash (#), RemoteAccess will
display the named text file from the textfile directory. For
example, suppose three entries looked like this:
5 : ?110
6 : C:\COMMAND.COM
7 : #WELCOME
Pressing ALT-F5 would cause RemoteAccess to exit to DOS with
an errorlevel of 110, ALT-F6 would execute a copy of
COMMAND.COM in a shell, and ALT-F7 would display the
appropriate (ASC/ANS) version of your WELCOME.A?? file to
the user.
22
Events
────────────────────────────────────────────────────────────
The RemoteAccess Event Editor allows you to set pre-
determined times during the week when RemoteAccess will
automatically exit to your batch file and perform certain
functions, usually some kind of system maintenance. Select
EVENTS from the main menu bar. This window contains all
event information. You may define up to 20 events to run at
any time during the day. In addition to this, it is also
possible to specify that an event only run on a particular
day or days of the week.
To modify an event, simply move the highlight bar to the
event you wish to alter, and press [CR]. Use the cursor keys
to move between entries in the event edit window, and enter
the time you want the event to start at, in 24 hour format.
Next, enter the errorlevel; when the event is activated,
RemoteAccess will exit to the batch file from which it was
called at this errorlevel. Your batch file should trap this
errorlevel and act accordingly. In this window, you can also
specify what days you would like the event to run on, and
whether the event is enabled or disabled. If a user's
upload or download overruns an event which is FORCED then
the transfer will be aborted and the user disconnected to
ensure that the event runs at the proper time. More
information on trapping events is contained in the BATCH
FILE EXAMPLES section.
23
Files
────────────────────────────────────────────────────────────
Select the FILE AREAS submenu. This is where you define
your file areas.
Usually your file areas will be grouped by area of interest.
For example, file area 1 might be "DOS utilities", area 2
"Pascal programming files", area 3 "Graphics picture files",
and so on.
Most of the entries here are fairly straightforward. The
FILE AREA NAME is the name of the file area as the user will
see it. The FILE PATH is a fully qualified directory path
that points to where the files in this area are stored, for
example C:\FILES\IBM\GAMES\. Note that the trailing
backslash is optional.
The list of files that your users see for a particular area
is generated from a textfile that you can edit yourself. By
default, this file is called FILES.BBS and is located in the
same directory as the files it describes. When a file is
uploaded to a file area, RemoteAccess creates a new
FILES.BBS if it doesn't already exist, and then appends a
single line entry for the file. The format of FILES.BBS is
simple:
<FILENAME.EXT> <Description>
Filenames that contain wildcard / pattern match characters
are expanded to full filename specs. A separate entry is
displayed for each matching file found.
The <Description> field may be up to 255 characters long.
When displayed to the user the description is automatically
word wrapped to the width of the user's screen.
If you have some kind of read-only mass storage device
online such as a CD-ROM, then it usually isn't possible to
have a FILES.BBS in each file directory. To get around this
problem simply create a separate directory to hold all of
the FILES.BBS files. The individual files should be names
FILES.n, where n is the file area number. For example -
C:\RA\CDROMLST\FILES.33
Is the file that would be read in place of FILES.BBS for
area number 33. In this example, the FILE LIST path (in the
PATHS section of RACONFIG) has been set to C:\RA\CDROMLST.
Access to each file area is controlled by raising the
SECURITY LEVEL and FLAGS to the minimum combination required
for a user to "see" the area. For example, if a user uses
the "Search for new files" function, only file areas to
which he/she has the required security/flags setting will be
checked. The EXTERNAL SUPPORT FILES section contains
information on marking files as free and/or password
protected under the subheading FILES.CTL.
24
Next go to the GLOBAL OPTIONS submenu.
The UPLOAD CREDIT FACTOR provides a way of rewarding your
users for uploading files to you. If this value is set to a
non-zero value, after each upload session, the user is
granted that many seconds per minute of upload time. So, if
you set the credit factor to 30 (seconds), and a user spends
10 minutes uploading, he/she would be granted an extra 5
minutes for that session. Note that during uploads the timer
is "frozen" in addition to this bonus.
When a user gets a list of files in a file area, the format
of a file entry is the file name, length, date and
description. It is possible to omit the date from each line,
thus making it possible to have more verbose descriptions by
setting SHOW FILE DATES to "No".
Note that the asterisk normally displayed immediately after
the date which indicates the file is new since the last log-
on is still displayed.
When a file is uploaded using a batch protocol such as
Zmodem, or Ymodem, the original date of the file is normally
preserved when the file is saved in the upload area. This is
of little use if the file was originally created in 1987, so
RemoteAccess will, if the RESET UPLOAD FILE DATES option is
enabled, reset the date stamp of the file to the date on
which it was uploaded.
When a user displays a list of files, the default action is
to show missing files as "<MISSING>". The next two options
determine whether these missing files are displayed, and if
so what message is displayed. {+} The message is only
configurable in the registered version.
It is possible to disable uploads when the amount of free
space on your upload drive falls below a preset level. For
example, to disable uploads if there is less than 1 megabyte
free, set MINIMUM UPLOAD SPACE to 1000 (kilobytes).
If the SCAN NEW FILES AT LOGON option is enabled, the user
will be given the opportunity to run a check for files which
are new since his/her last call.
The INTERNAL PROTOCOLS submenu allows you to disable,
enable, or make available only on an error-free (ie. MNP)
connect, any of the six internal protocols. {+} This is only
available in the registered version.
25
Select the EXTERNAL PROTOCOLS submenu. This option allows
you to interface up to fifteen external protocols for your
users to use, in addition to the six that are built-in.
When a user selects to upload or download a file, he/she
is presented with a hard-coded menu that lists the
available protocols, including your external ones.
The NAME field is the protocol name that the user sees
in this menu. The KEY is the keypress that should
activate the protocol. Note that the KEY must be unique.
In other words, since [Z]modem is an internal protocol, you
can't use [Z] to activate an external protocol.
Before RemoteAccess activates the external protocol, it
creates a control file that tells the protocol which files
to send or receive. This file consists of some general
information and a list of files, one per line. You may
define exactly what each line looks like. If you select
EXTENDED CONTROL FILE, then RemoteAccess will write the
information needed by Opus-compatible external protocols at
the beginning of the file before the file list. Check the
documentation for each protocol you install to determine
whether it is "Opus compatible".
If the protocol has the capability to send or receive more
than one file at a time, set BATCH AVAILABLE to "Yes".
You may temporarily disable the current protocol by setting
its status to DISABLED, re-enabling it later by setting it
to ENABLED.
The LOG FILE NAME is the full path and name of the log file
that the external protocol writes. This file contains
information about what files were actually sent or received.
Without this information, RemoteAccess will not be able to
update the user's record. Most protocols have the facility
to create a log of the files that were actually sent or
received; if the protocol you are installing doesn't, it is
advisable not to use it.
The CONTROL FILE NAME is the full path and name of the
control file that RemoteAccess creates before activating the
protocol. In order to allow the use of as many different
protocols as possible, you have full control over the format
of this file. The DOWNLOAD CONTROL STRING determaines the
format of each file entry. Inserting a "@" in the string
substitutes that position with the file name. For example,
if you wanted to download the file
C:\FILES\IBM\FUN\CASINO.ZIP using an Opus type external
protocol, you would set the control file string to:
Send @
When the control file is created, this would be expanded to:
Send C:\FILES\IBM\FUN\CASINO.ZIP
26
If the user were to select a batch download, say RA*.ZIP,
the wildcard/pattern match is expanded to a full list of
fully qualified path and file names.
The UPLOAD CONTROL STRING works in exactly the same way,
except that for batch uploads, instead of specifying the
full file name, it substitutes just the path to the upload
directory, as the filenames are not known prior to the
upload.
UPLOAD/DOWNLOAD COMMAND LINE tells RemoteAccess what program
name to execute in order to activate the external protocol.
It is possible to insert variables into the command line
using special control characters. For example, the string:
PROTNAME.EXE Send *B
would be expanded to:
PROTNAME.EXE Send 2400
For a full list of special control codes, refer to the
description of a Type 7 menu command in the MENU COMMANDS
section. In addition to these codes, the # symbol can be
used if the filename to send or receive needs to be
specified on the command line.
When the external protocol has finished and control is
returned to RemoteAccess, the log file that was created is
scanned to extract information about what files were sent or
received. RemoteAccess scans the file for the UPLOAD or
DOWNLOAD LOG KEYWORD. As soon as it finds that word, it will
scan forward x number of words to get the name of the file
transferred and a description, if available. To illustrate
how this works, look at this extract from a BiModem log:
= 10 Sep 14:10:10 BMOD DL-B \GRAPHICS\FORMATS\LOCKLEAR.ZIP
= 10 Sep 14:12:22 BMOD DL-B \GRAPHICS\FORMATS\AWESOME.ZIP
The DOWNLOAD LOG KEYWORD can be any word in the log file
that indicates the transfer of a single file. The keyword
would be set to "DL-B", and the NAME WORD # set to 1.
RemoteAccess scans the above entries until it hits "DL-B",
and then counts forward 1 word to get the file name. Uploads
work in the same way, but a description word number may also
be specified, as some protocols get file descriptions from
the user directly. If RemoteAccess finds a description it is
appended to the end of the FILES.BBS file, otherwise the
user is prompted for the description.
27
Example : Installing Lynx as an external protocol
-------------------------------------------------
Select an empty protocol slot, and enter the following
information:
Name : Lynx
Key : L
Extended control file : No
Batch available : Yes
Status : Enabled
Log file name : C:\Ra\Dszlog.Txt
Control file name : C:\Ra\Lynx.Ctl
Download command line : Lynx.Exe S /*P /*B /S /H @Lynx.Ctl
Upload command line : Lynx.Exe R /*P /*B /S /D /H #
Download ctl string : @
Upload ctl string :
Download log keyword : x
Upload log keyword : X
Log : Name word # : 10
Log : Desc word # : 0
(Note the case of the upload and download log keyword
entries).
The above example assumes that your system directory is
C:\RA. To complete the installation, you'll need to set the
DSZLOG environment variable to the full path and name of the
log file that Lynx writes:
SET DSZLOG=C:\Ra\Dszlog.Txt
28
Messages
────────────────────────────────────────────────────────────
The last configuration section is the message areas. From
the MESSAGES menu, select MESSAGE AREAS. You may define up
to 200 different areas, each with it's own attributes and
security requirements.
Firstly, give the area a name. This should be a meaningful
description of its content, for example "IBM Users",
"Cooking", or "Entertainment". Avoid using names like
"Message Area 1". If you wish to "delete" the message area,
simply set the area name to nothing.
Each area can be one of three TYPES. LOCAL, if the message
area is available on your BBS only, or if you are in a mail
network such as FidoNet, ECHOMAIL or NETMAIL. These latter
two types are explained more fully in the MAIL NETWORKING
section. If you are not part of a mail network, set the type
to LOCAL.
MESSAGE STATUS controls the types of messages that users are
allowed to post in the area. You have the choice of PRIVATE
ONLY, PUBLIC ONLY, PRIVATE/PUBLIC and READ ONLY. It may be
desirable to allow only public messages in general
discussion areas, or likewise private only in user-to-user
message areas to ensure that all messages in that area may
be read only by the sender or the recipient of the message.
Message areas marked as READ ONLY may only have messages
posted in them by the sysop. This is useful for, say a
general announcement area.
Each message area may be configured via the USER NAMES
option, to allow users to post messages with real names
only, handles only (this is the user's permanent
"registered" handle), or with an alias which the user may
select at the time the message is posted. RemoteAccess will
not allow the use of the alias "Sysop".
The next three options are used by RAMSG, the message-base
maintenance utility. In order to keep the size of your
message-base files down to a reasonable level it is
necessary to regularly delete "old" messages. You should set
these options according to the requirements of each area.
For further details, see the section on maintaining the
message database files.
29
For example, if the area is high-traffic, by setting DAYS
UNTIL OLD MESSAGES ARE KILLED to 7, RAMSG will delete any
message in that area that is over a week old. You can use
these options in combination. By setting DAYS UNTIL OLD
MESSAGES ARE KILLED to 14 and MAXIMUM NUMBER OF MESSAGES to
200, RAMSG will delete any message in that area which is
either over 14 days old as well as the oldest messages in
the area until there are only 200 messages left. If the
message area is important, say user-to-user private mail,
you can instruct RAMSG to delete only messages which have
already been received that are a certain number of days old
by setting the DAYS AFTER RECEIVED MESSAGES ARE KILLED
option.
The default action for an EchoMail message area is to append
an origin line (see the section on MAIL NETWORKING for more
on this) to each outgoing message. This may be disabled by
setting the APPEND ECHOMAIL INFO flag to "No".
The ALLOW COMBINED ACCESS flag determines whether users may
select the current message area as part of their combined
message area configuration.
RemoteAccess provides an extremely powerful facility which
allows users to attach one or more files to a message. This
means that users can send each other files privately. To
enable this option, set ALLOW FILE ATTACHES to "Yes". Also
ensure that the FILE ATTACH PATH in the OTHER/PATHS submenu
points to a directory which exists. When a user uploads
files with a message, RemoteAccess creates a uniquely named
subdirectory in this directory, and places all the attached
files in it. After the recipient has received the message
and confirmed that he/she received all the files, all the
files and the directory are deleted. {+} This feature is
only available in the registered version.
The AKA ADDRESS and ORIGIN LINE options are used for
EchoMail type areas. You can set different origin lines for
each area, along with any one of your network addresses, to
be appended to the end of messages that are posted in the
area. If no origin line is specified, then RemoteAccess will
use the origin line defined in the DEFAULT ORIGIN LINE
option.
Access to the message area is controlled by READ, WRITE and
SYSOP security levels and access flags. Read Security is the
minimum security level the user needs to be allowed to read
messages in each message area. Likewise, message posting and
replying is only permitted if the user's security level is
equal to or higher than the Write Security setting. SYSOP
security access permits reading of all messages in the area,
even if they are private and addressed to another user. This
is useful for message areas which are run by assistant
sysops and the like, so they can check messages for suitable
content and delete off-topic ones. A full discussion on
security can be found in the SECURITY section.
30
Select the GLOBAL OPTIONS submenu.
CHECK FOR MAIL AT LOG-ON, when enabled, will force the
system to scan the message-base for new mail addressed to
the user (regardless of what area it is in, provided the
user has access to that area) at log-on.
The FULL MAIL CHECK option determines the type of mail check
that is performed. A full check scans from the start to the
end of the message-base for all mail addressed to the user
that does not have the "Received" flag set. If you set the
option to "Off", the message base is only checked from the
last message that the user read. While this is much faster,
there is the possibility that some mail may be skipped if
the user elected not to read his/her mail during the last
logon.
The QUOTE STRING is a highlight character that RemoteAccess
will place in front of any message that is replied to. For
example, a message quoted using " > " as the quoter would
look like:
> I have been using RemoteAccess for 2 months now and
> love it!
I have to agree with you there, Tom. Flexibility-wise
you just can't beat it.
A '@' character in the quote string will be translated into
the initials of the person whose message is being quoted.
If the RENUMBER THRESHOLD option is set to a non-zero value,
RAMSG will automatically renumber the entire message
database when the highest message number reaches the
predetermined value.
EXTERNAL EDITOR. This is the DOS command line that will be
used to activate a full screen message editor, if one is
installed. This option is available only to users of ANSI
graphics. The full screen editor is a third-party package
that enables messages to be entered in a "word-processing"
environment, with cursor movement and text formatting
ability. QuickEd is one such package that interfaces
directly to RemoteAccess. This command line may contain any
of the metacommands listed in the description of the type 7
menu command, including *M to swap RemoteAccess out of
memory before the editor is loaded.
Set the ORIGIN LINE to the message you would like appended
to all outgoing EchoMail messages. This will take effect in
all areas except where you have entered a specific origin
line for a particular area.
31
The REPLY HEADER is displayed at the top of a message when a
user replies to a message that was not originally addressed
to him/her. The following macro characters may be used:
@ - Person the original message was addressed to,
# - Person who posted the original message,
` - Date of the original message,
~ - Time of the original message.
The last three options in this submenu relate to sending
netmail messages as "crash", or immediately, and attaching
files to netmail messages.
The DEFAULT COMBINED SETTINGS submenu allows you to
predefine the initial combined mesage area configuration
that is given to new users.
Go to the QUIT menu, and select "Yes" to save any changes
that have been made. This completes the tutorial on
RACONFIG.
32
SECURITY
────────────────────────────────────────────────────────────
All user-security is controlled by a security level and set
of access flags. The security level is any number from 1 to
64,000. Setting a user's security level to zero will lock
him or her out of the BBS. There are thirty-two access flags
arranged in four sets of eight individual flags, each of
which can be either ON or OFF. An ON flag is represented by
an "X", and an OFF flag by a "-".
Firstly let's look at menu security. Each menu is made up of
a number of lines, each of which may have a command
associated with it. (The structure of menus is explained
fully in the next section). In order for a menu line to be
visible (and selectable) to a user, the user's security
level must be equal to or greater than the security level
assigned to that line. In addition to this, every flag that
is set ON in the menu line must also be set ON in the user's
flag setting.
Read/Write and Sysop access to message areas is controlled
in the same way. To be able to read messages in an area, the
user must have not only a sufficient security level, but
also at least the flags that are defined in RACONFIG for
that area. Similarly, the file area access security/flag
system works in the same way, BUT the settings only affect
the three file search menu functions. To restrict
up/download access to certain areas, you will have to use
menu security.
33
MENUS
────────────────────────────────────────────────────────────
This is possibly the most important stage in configuring
your BBS. The menus that you create will give the system
it's own "feel", and will make your system look completely
different from the one next door. The menu system gives you
one hundred percent flexibility not only cosmetically, but
in allowing and disallowing access to certain functions and
parts of your BBS to groups of users.
The menus are line-oriented. Using the menu editor supplied,
you enter the lines one at a time. Each line has a line of
text that is displayed to the user, a menu "type", a minimum
security level and flag setting required to access that
line, and some optional data that is used by some menu
types.
There are approximately sixty menu functions that may be
activated by the user pressing the key you have linked to
that function. These functions are explained fully in the
following pages.
34
Menu functions
Type : 1
Name : Goto another menu
Optional Data : <Menu Name> [Password] [/F=<File Area>|+|-]
[/M=<Message Area>|+|-]
This function causes a jump to another menu, which has been
created with the editor and saved as <Menu Name>. If
[Password] is specified then the user will be asked to
supply a non-case-sensitive password before proceeding.
<File Area> and <Message Area> set the currently selected
file and message areas respectively for the template system.
See the section on MENU TEMPLATES for a full explanation on
this.
Type : 2
Name : Gosub another menu
Optional Data : <Menu Name> [Password] [/F=<File Area>|+|-]
[/M=<Message Area>|+|-]
As for Function 1, but saves the path to the last menu on a
"stack", making it possible to return to the calling menu
with a type 3 function. Note that menus called in this way
may be nested to a maximum of 50 levels.
Type : 3
Name : Return from gosub
Optional Data : None
Use this function to return from a Gosub (type 2) to the
previous menu.
Type : 4
Name : Goto menu after clearing menu stack
Optional Data : <Menu Name> [Password] [/F=<File Area>|+|-]
[/M=<Message Area>|+|-]
As for function 1, but before jumping to the new menu, the
gosub menu stack is cleared. Obviously you can't use a type
3 return straight after this!
35
Type : 5
Name : Display a *.ASC/*.ANS text file
Optional Data : <1-8 character name>
Displays a file in your textfile directory (as defined in
RACONFIG). If the user has ANSI enabled, then <Filename.ANS>
will be displayed. If the user does not have ANSI enabled,
or <Filename.ANS> is missing then <Filename.ASC> will be
displayed. It is possible to display comprehensive system
and user details by inserting special control codes in the
file. These codes are listed in the TEXT FILE CONTROL CODES
section.
36
Type : 6
Name : Bulletin menu
Optional Data : <1-8 character name>
Displays the <1-8 character name> file in your text file
directory as does function type 5. The user is then prompted
for a file suffix of length 8 - <length of file>. The suffix
is appended to the original file name, and that text file is
displayed as it would be in a type 5 function. For example,
if the optional data field contained a file name of
BULLET, the file BULLET.ASC/ANS would be displayed. Then
the user is prompted for a 2 character input. If the user
typed in "1B", then the file "BULLET1B.ASC/ANS" would be
displayed. The original text file defined in the optional
data should therefore contain a list of available bulletins.
37
Type : 7
Name : Run an external program in a shell
Optional Data : <Command Line> [Control Codes]
This command will run an external program (a "door") in a
shell while the user is on-line. Examples are on line games,
mail-checking facilities and so on. (Refer also to type 15 -
Exit to DOS for an alternative way of running external
programs). The FULL name of the program must be specified if
it is an .EXE or .COM file. To run one of these two simply
put the name of the program in the optional data field. If
you wish to call a batch file, this must be done via
COMMAND.COM, the memory-resident command-line processor. So
to run your TradeWars batch file, the command line could
read:
C:\COMMAND.COM /C \BBS\DOORS\TW2.BAT
Many programs require extra information to be passed on the
command line, so the following control codes may be used. In
each case, the code is replaced by it's value:
*A : Write the user's handle (if any) in DORINFO.DEF
instead of the user's real name.
*B : User's baud rate, or 0 if local
*C : Full path and name to COMMAND.COM
*D : Automatically generate the Doorway DOOR.SYS
parameter file.
*F : User's first name
*G : ANSI graphics, 0=Off/1=On
*H : Normally the FOSSIL is de-initialised before
running an external program to avoid any possible
conflicts between the FOSSIL and the program.
Specifying this parameter leaves the FOSSIL "hot"
or active.
*L : User's last name
*M : Activate MemorySwap feature. RemoteAccess attempts
to swap itself and all the memory it occupies to
EMS (if installed) and disk, leaving only 20k
resident. Great for running memory-hungry
programs, but it takes a few seconds to do the
swap. If it can't do the swap, it will try a
normal shell. NOTE : Some programs are notorious
for "fragmenting" memory, and will not work with
MemorySwap. Programs compiled in QuickBASIC, such
as TradeWars 1000 exhibit this problem.
*N : Line number, as specified by the -N command line
parameter
38
*Oxxx : Override the baudrate value passed on to the
called program with xxx.
*P : Communications port being used (1-4)
*R : User's record number in the user file
*T : Time remaining for current call
*! : Freeze the system timer for the duration of the
shell. Useful for running external utilities like
full-screen chat programs etc.
*# : Turn off the "Wants Chat" indicator on return
from the shell. This is to facilitate proper
installation of external chat utilities.
*0 : The full path to the currently selected file
template area.
*1 : The number of the currently selected template
message area.
In addition to this command line information that can be
passed, RemoteAccess also creates two data files before the
shell. DORINFO1.DEF, which is a RBBS-compatible file, and
EXITINFO.BBS, which contains an extremely comprehensive
amount of system and user information. The structure of this
file can be found in the RemoteAccess structures document,
RASTRUCT. It should also be noted that ALL system files are
written to and closed off before the shell is activated,
then reopened and scanned upon return. This means that
programs that modify system files (eg. USERS.BBS) can be
safely run in a type 7 shell.
RemoteAccess also supports Doorway's DOOR.SYS parameter file
directly; including a *D on the command line enables the
generation of this file.
Note that the external program must do it's own time limit
and carrier watchdogging, in the event that the user does
not exit from the program correctly.
39
Type : 8
Name : Product information
Optional Data : None
Displays product information including the version number
and copyright information. If a user is on-line remotely,
the name and version of the FOSSIL in use is also displayed.
Type : 9
Name : Terminate the session
Optional Data : None
Displays the GOODBYE.ASC/ANS text file and hangs up on the
user by dropping the DTR signal to the modem. To this end,
make sure your modem's DTR line is not "forced high"
continuously.
Type : 10
Name : System usage
Optional Data : None
Displays a nicely formatted full-screen autoscaling graph
that depicts system usage in terms of percentage use per
hour. To reset this graph, delete the file "TIMELOG.BBS"
from your system directory.
40
Type : 11
Name : Page sysop to chat
Optional Data : <Paging string>
Displays the <paging string> to the user and pages the sysop
for a chat. If the REASON FOR PAGE option has been enabled
in RACONFIG, RemoteAccess will display a user-defined prompt
and wait for the user to enter a reason for requesting a
chat. The sysop may select "C" to chat with the user, or "A"
to abort the page. You may break in for a chat at any time
by pressing ALT-C. All sysop keys are listed in the
reference section of this manual. During a chat, the system
timer is "frozen", and is re-started when the chat is
terminated. The sysop terminates chat mode with the ESCape
key. During chat, you may open a capture file to log the
chat session by pressing CTRL-A, and again to close the
capture.
The default paging sound is a constant "beep-beep" tone for
the duration of the page. You may define your own page sound
by creating a text file called PAGE.RA in the system
directory. The following keywords are valid:
TONE [hz] [1/100's sec] (sounds hz)
WAIT [1/100's sec] (sounds nothing)
The following table lists several musical octaves and the
correct frequency value associated with each note:
Note Oct - 1 2 3 4 5 6
----
C F 45 134 268 536 1071 2145
C# r 71 142 284 568 1136 2273
D e 75 150 301 602 1204 2408
D# q 80 159 319 638 1275 2551
E u 84 169 338 676 1351 2703
F e 90 179 358 716 1432 2864
F# n 95 190 379 758 1517 3034
G c 100 201 402 804 1607 3215
G# y 106 213 426 851 1703 3406
A # 113 225 451 902 1804 3608
A# 119 239 478 956 1991 3823
B 127 253 506 1012 2025 4050
The RemoteAccess distribution archive contains a sample
PAGE.RA file to get you started.
41
Type : 12
Name : Questionnaire
Optional Data : <1-8 character file name> [/N]
Initiates a questionnaire. The <file name> is the first part
of the name of the questionnaire file. All questionnaire
files are stored in the system directory, and have a name
extension of .Q-A. User's responses are stored in an output
file named <file name>.ASW. There is a full tutorial on
questionnaires, including the script language in the
reference section of this manual.
RemoteAccess has two hard-coded questionnaires. If present,
it will initiate the questionnaire NEWUSER.Q-A for a new
user after the hard-coded text file NEWUSER2.ASC/ANS
is displayed.
The SUBDATE.Q-A questionnaire is automatically initiated
when a user logs on and his/her subscription date has
expired. You could use this questionnaire to possibly
downgrade the user's security and/or flag settings and
display a message informing the user that his/her
subscription has expired.
For information on hard-coded (external support) files,
refer to the EXTERNAL SUPPORT FILES section.
Normally the initiation of a questionnaire is noted in the
system log. Placing the /N parameter after the questionnaire
name on the optional data line will suppress this log entry.
42
Type : 13
Name : User listing
Optional Data : [/G]
Displays a list of users in the user file. Lists users name,
location, file ratio, and the last time he/she called the
system. This function has some basic pattern matching
capabilities on the name field. By default all users are
listed. However, if a /G is specified in the optional data
field then the user will only see users who are in the same
group. Note that this restriction does not apply to the
sysop.
Type : 14
Name : Time
Optional Data : None
Shows the current date and time, along with the user's daily
time limit, time used and time remaining for the day.
43
Type : 15
Name : Exit to DOS
Optional Data : <Errorlevel>
This function causes RemoteAccess exit to the batch file
that executed it, with a specific errorlevel. Set the
optional data to the errorlevel you wish to pass to the
batch file. The batch file should trap the errorlevel and
act accordingly. If you exit while the user is still on-
line, to log the user back on invoke RemoteAccess with the -
R command line parameter. This will force it to read the
EXITINFO file that was written at the time of the previous
exit and take the user directly to the top menu. Note that
errorlevels 0 to 5 are reserved by RemoteAccess for system
use (see the reference section on ERRORLEVELS for a complete
list and description of these and how to use them), and
should not be used.
There are two control codes that are valid on the optional
data field:
*A : Pass the user's handle/alias in DORINFO.DEF
*D : Generate the DOOR.SYS file
See the description of the menu command type 7 for
additional information on both of these options.
44
Type : 16
Name : Alter location
Optional Data : None
Allows the user to change the "location" field in his/her
user record.
Type : 17
Name : Alter password
Optional Data : None
Allows the user to change his/her password. Frequent
password changes should be encouraged to ensure system
security, and in fact there is an option to force a change
of password every certain number logons (refer to
"RACONFIG").
Type : 18
Name : Alter screen length
Optional Data : None
Allows the user to alter the length of his/her screen
display. This affects the "Continue?" prompt.
Type : 19
Name : Toggle screen clearing
Optional Data : None
Allows the user to specify whether he/she would like screen
clearing codes sent.
Type : 20
Name : Toggle page pausing
Optional Data : None
Allows the user to enable or disable the "Continue?" prompt
at the end of each screen page.
Type : 21
Name : Toggle ANSI graphics
Optional Data : None
Allows the user to select, or deselect ANSI graphics. If the
user disables ANSI, use of the full screen message editor is
also disabled.
45
Type : 22
Name : Check the mailbox
Optional Data : None
Checks to see if there is any mail addressed to the user
that he/she hasn't yet read. This can be done automatically
at log-on by setting the appropriate option in RACONFIG. See
the section on configuration for details of the two types of
mail-check available. All new messages are marked for later
retrieval with the "Read Marked" option. Note that the user
will only be notified of mail in areas that he/she has read
access to, as defined in RACONFIG. Although the system only
prompts the user with a "Read mail now [Yes/no]" prompt,
several options can be activated. Valid choices are [R]ead,
[S]can, [Q]uickscan, [K]ill, or [M]ark as received.
46
Type : 23
Name : Read messages
Optional Data : <Message area #> or /M
Initiates the message reading routines. Checks that the user
has read access to the message area first. The user may
select several different scan modes. These include forward,
reverse, new messages, marked messages, individual message,
or a selected scan according to the "To:", "From:" or
"Subject" fields. Online help is also available from this
hard-coded menu in the form of a text file. Put the message
area number on the optional data field, or 0 to select
"combined" mode (see function type 28 for more on this
feature). If you put a "/M" in the optional data field in
place of the area number, RemoteAccess will automatically
substitute the currently selected template message area into
the data field. See MENU TEMPLATES for more on this. The
message area number refers to number assigned to the desired
area in RACONFIG.
The menu bar at the end of each message provides the
following functions:
[-] : Read previous reply
[+] : Read next reply
[A] : Redisplay message again
[N] : Go to the next message
[L] : Go back to the previous message
[R] : Post a reply to the current message
[E] : Enter a new message in the current area
[F] : Download files that are attached to the message
[D] : Delete the displayed message (check the "delete msg"
menu function for more information)
[S] : Stop reading messages
The following options are available only to users who have
sysop access to the message area:
[!] : Display ^A kludge lines normally hidden
[*] : Edit the current message's attributes
[X] : Export message to a file or the printer
[/] : Forward message to another user in any area
[=] : Mark message as unreceived and go to the next message
[U] : Modify the security level of the user who posted the
currently displayed message, provided the user is
listed in the userfile. Great for "on the fly" user
verification! {+} Only available in registered
version.
47
Type : 24
Name : Scan messages
Optional Data : <Message area #> or /M
Same as the READ message function (type 23) but only
displays the message header of each message. The user also
has the option of marking messages for later retrieval.
Type : 25
Name : QuickScan messages
Optional Data : <Message area #> or /M
Same as the READ message function (type 23) but each message
is listed as a single-line entry containing message number,
the poster of the message, who it is addressed to, and the
subject line.
Type : 26
Name : Delete message
Optional Data : None
Allows a user to delete a message provided that:
* The user has sysop access to the area the message is in,
OR
* The message is in a LOCAL or NETMAIL area and the user is
the sender or recipient of the message, OR
* The message is in an echomail area and the user is the
sender of the message, provided the message has not been
exported from the message-base.
48
Type : 27
Name : Post message
Optional Data : <Message Area #> or /M [/L] [/T=<Name>]
Post a message in the specified area (or the currently
selected template area if the "/M" is used). The user must
have either write or sysop access to the message area, as
defined in RACONFIG. The /L option will log the user off
immediately after the message is saved (useful for a "Leave
message to sysop before disconnecting" option). The /T=
option will force the message to be addressed to a specific
user. Simply place the user's name in the optional data
field after the /T= parameter to select this option. For
example, on my "log-off" menu, I have the following entry:
Menu Type 27
Optional Data: 60 /L /T=Andrew_Milner
(Any messages to "Sysop" are redirected to the sysop's name
as defined in RACONFIG). If you do use a full name, be sure
to use underscores in place of spaces.
Specifying a message area number of zero forces RemoteAccess
to display all message areas that the user has write access
to and prompt for the message area to post the message in.
49
Type : 28
Name : Select combined areas
Optional Data : None
Allows the user to select any combination of message areas
for "combined" mode message reading/scanning/quickscanning.
The user is shown a list of available areas and may toggle
any of them "ON" or "OFF". This combination of areas is
saved as part of the user's permanent user record, and is
restored at next log on. To read messages on the "combined"
area, use a normal read/scan/quickscan menu function but set
the message area number in the optional data field to zero.
Area zero is hard-coded as this combined area and cannot be
defined by the sysop. Note that it is possible to define via
RACONFIG a default selection of combined message areas for
new users.
50
Type : 29
Name : Move a file
Optional Data : <Full source path>
Primarily intended as a sysop/assistant sysop function, this
allows the user to move files from a pre-defined area
<source-path> to any valid DOS directory without the need
for remote access to DOS. After the file has been copied
successfully, RemoteAccess will optionally move the file's
description (if there is one) to the destination directory.
Type : 30
Name : Directory
Optional Data : <Full path> or /F
Displays an MS-DOS style directory of the directory
specified in the optional data field, showing name, length
and date of each file. The user is prompted for an optional
wildcard / pattern match filespec.
Type : 31
Name : List files
Optional Data : <Full path> or /F
This option displays a list of files available for download
from the directory specified by the path name in the
optional data field. The file names and descriptions are
contained in a file called FILES.BBS. This file is
automatically maintained by RemoteAccess when files are
uploaded, but it may also be edited by the sysop. The file
consists of a single word file-name per line with a
description, up to 255 characters in length. Descriptions
that exceed the width of the screen are automatically
wrapped to the next line. The upload date and length of each
file is also displayed (optionally), and an asterisk before
the description signifies that the file is new since the
user's last call.
If, instead of the full path to the file area, you put a
"/F", RemoteAccess will substitute the path name that
corresponds to the currently selected template file area, as
defined in RACONFIG. See the MENU TEMPLATE section for
further information on this.
51
Type : 32
Name : Download a file from area
Optional Data : <Full path> or /F [Password]
Enables the user to download any file that is contained in
the specified directory. Note that the file need not be
listed in that directory's FILES.BBS for the user to be able
to download it. If a password is specified, the user will be
asked for a non case-sensitive password before being allowed
to proceed with the transfer. The /F option works in the
same way as in function 31.
Type : 33
Name : Upload a file
Optional Data : <Full path> or /F
Enables the user to upload (send) a file to your system. The
file will be placed in the directory specified in the
optional data path. FILES.BBS will be automatically updated
to reflect the upload. The /F option works in the same way
as in function 31 and 32.
Type : 34
Name : View archive
Optional Data : <Full path> or /F
Allows the user to view the contents of an archived file in
the specified directory. At present, only ZIP and LZH files
are supported, but this will be expanded in the future. Menu
templating is supported with the /F option. This is
explained more fully in MENU TEMPLATES.
Type : 35
Name : File scan by keyword
Optional Data : [area1 area2 area3 ...]
This function uses the data specified in RACONFIG to search
all file areas that the user has access to for a key-word
that is supplied by the user. Any FILES.BBS entries that
match are displayed with the name of the area the match was
found in. The default is to scan all areas, but you may
specify that only certain areas be searched by putting the
area numbers to include on the optional data line.
52
Type : 36
Name : File scan by file name
Optional Data : [area1 area2 area3 ...]
Same as function 35, but scans for an exact file name match.
Wildcard and pattern matching characters are valid. The
default is to scan all areas, but you may specify that only
certain areas be searched by putting the area numbers to
include on the optional data line.
Type : 37
Name : Show new files
Optional Data : [area1 area2 area3 ...]
Scans all file areas that the user has access to for files
that have a date more recent than the date specified by
the user. The default is to search for files new since the
users last log-on. The default is to scan all areas, but you
may specify that only certain areas be searched by putting
the area numbers to include on the optional data line.
Type : 38
Name : Type (view) a text file
Optional Data : <Full path> or /F
Allows the user to type to the terminal the contents of a
plain ASCII/ANSI text file in the specified directory. This
is useful for on-line file lists or magazines. The /F option
overrides the path name with the currently selected template
file area path.
Type : 39
Name : Display a fully named text file
Optional Data : <Full path and name>
Similar to the type 5 function, but allows you to specify
the full path and name (including extension) of the file
that will be displayed. Like the type 5 function, this also
interprets the special control characters.
Type : 40
Name : Display an ASC/ANS text file with hot keys
Optional Data : <1-8 character name>
Displays an ASC/ANS text file the same way as a type 5
would, but leaves the current menu hot keys active while the
file is displayed. This allows the use of elaborate graphics
in your menus that would be impossible to create with the
line editor. See also AUTOMATIC COMMAND EXECUTION for
details on how to integrate these files into your menus.
53
Type : 41
Name : Toggle full screen editor
Optional Data : None
Allows the user to select or deselect the use of the full
screen message editor. Use of the editor is only permitted
if the user has ANSI graphics enabled.
Type : 42
Name : Toggle hot-keys
Optional Data : None
Allows the user to choose between hot-keys or command
stacking. In command stacking mode, several commands, or
key-presses, can be specified on one command line by putting
a semi-colon in between each command.
Type : 43
Name : NewMail {+}
Optional Data : None
Display a full list of all the message areas the user has
read access to, highlighting those that contain unread
messages. This menu command is available only in registered
only mode.
Type : 44
Name : Reset combined areas setting
Optional Data : None
Allows the user turn ON or OFF all available message areas
for his/her combined message area setting.
Type : 45
Name : Display text file and wait
Optional Data : <1-8 character name>
This is the same as a type 5 function, but prompts the user
to press [Return] before continuing. This is useful for
displaying text files that are generated automatically by
utilities that don't append a Control-A (wait character) at
the end of the file.
Type : 46
Name : Display direct textfile with CR
Optional Data : <Full path and name>
Displays a text file with a fully qualified path and name
and waits for the user to press [Return] before continuing.
54
Type : 47
Name : Make a log entry
Optional Data : <Log entry>
When this command is executed, it simply takes the contents
of the Optional Data field and writes it to the system log
as if it were a normal hard-coded log entry. The only macro
characters that are valid are:
@ : Insert the name of the current template file area
` : Insert the name of the current template msg area
Type : 48
Name : Download a specific file
Optional Data : <Full path and name>
Enables the user to download a file or set of files that you
have pre-defined, using a protocol of the user's choice.
Note that you may specify wild-cards and pattern match
characters in the file name, but if you do, the user will be
forced to use a batch transfer protocol. For example, a type
48 command with the following optional data field:
C:\FILES\RA\RELEASE\RA*.ZIP
Would send all files in the C:\FILES\RA\RELEASE directory
that matched RA*.ZIP.
Type : 49
Name : Select message area
Optional Data : None
Displays a list of all message areas the user has read
access to, and asks the user to select one by number. The
current message template area number is set to the users
choice. This allows the sysop to run a very low maintenance
system, since all that is required to add or delete a
message area is to modify the configuration file via
RACONFIG.
Type : 50
Name : Select file area
Optional Data : None
This operates in the same way as the "select message area"
(type 49) menu function, but uses file areas instead of
message areas.
55
Type : 51
Name : List today's callers
Optional Data : None
Lists every caller that has called your system since
midnight along with log on/off times, baud rate and what
line the call was taken on.
Type : 52
Name : Show all users on-line
Optional Data : None
Lists all users currently on-line. This would only be useful
in a multi-line installation. It shows where each caller is
calling from, their baud rate, the line they are
connected to and what they are doing.
Type : 53
Name : Toggle "Do not disturb"
Optional Data : None
This another multi-line feature only. It allows the user
turn on or off the ability of other users to send him/her
messages whith the type 54 function, like - "Hey Joe, I
noticed that you're on line 3. Wanna chat?" Note that the
sysop has the ability to override this and send a message
anyway.
Type : 54
Name : Send an on-line message
Optional Data : None
Allows the user to send a message to another user who is
logged on to another line at the same time. Provided that
the other user has not set his/her "do not disturb" flag,
the sender will be prompted for a one-liner to transmit.
Depending on what the recipient is doing at the time, he/she
will get the message ten to fifteen seconds later.
Type : 55
Name : Download any file
Optional Data : None
This is an extremely powerful function that should be only
accessible by the sysop. It allows the user to download a
file from any valid drive or directory using any of the
available file transfer protocols. Note that this the ONLY
download function that takes no account of download limits,
file ratios or transfer time, and does not update the users
record to reflect the download.
56
Type : 56
Name : Browse the nodelist {+}
Optional Data : None
Allows the user to browse the nodelist. Includes functions
to list all zones, list all nets and regions in a zone, and
list all nodes in a net or region.
Type : 57
Name : Change home/voice number
Optional Data : None
Allows the user to modify his/her home/voice phone number
permanently.
Type : 58
Name : Change business/data number
Optional Data : None
Allows the user to modify his/her business/data phone number
permanently.
Type : 59
Name : Global download {+}
Optional Data : None
Allows the user to download files as per the type 32
donwload command, but searches ALL areas the user has access
to for the requested file(s). All normal time and other
security restrictions apply.
Type : 60
Name : Change handle
Optional Data : None
Allows the user to select a new handle. Note that it will
not allow the user to choose a name which is in use by
another user. It will also not allow the use of "SYSOP" as a
handle.
Type : 61
Name : Toggle AVATAR
Optional Data : None
Toggles the use of AVATAR codes (see the section on TERMINAL
EMULATIONS for more information).
57
Type : 62
Name : Toggle full screen message viewer
Optional Data : None
Allows the user to select or deselect of the full screen
message presentation manager. When active, this option
displays all messages with a fixed header and uses ANSI and
AVATAR codes for special screen manipulation.
58
Automatic command execution
────────────────────────────────────────────────────────────
Normally a menu function would be activated when a user
presses the key that you have linked to that function.
However, it is possible to cause a function to be executed
automatically as soon as a menu is displayed by setting the
entry to "auto execute". As soon as that particular menu
line is displayed the function is executed
automatically, without the need for the user to select the
option. This is a very powerful feature when used with the
type 40 menu function, which displays an ASCII/ANSI text
file while checking for menu hot-keys. By setting up the
first line of a menu as a type 40 with automatic execution,
as soon as the menu is called your text file is displayed
instead of the normal menu lines. This allows you to design
very elaborate graphical menu displays that contain extra
information about the user by inserting the special text
file control codes. What happens if a user "passes through"
a menu by using a stacked menu command? In some cases you
may want the automatic command to execute, for example to
redirect the user to another menu by automatic execution of
a type 1 or 2. On the other hand, if the command is only for
cosmetic purposes (maybe a text file to display some user
statistics) it would be better to skip the command and
continue straight to the next menu. The rule is that the
menu command will only be executed if it is the first entry
in the menu AND it is not a 'display textfile' type
function.
Special optional data switches
────────────────────────────────────────────────────────────
There are two special "switches" which may be placed at the
end of the optional data field for any menu command:
/NS : This switch suppresses the usual clear screen code
that RemoteAccess sends when a new menu is
displayed, and is only useful when used with a menu
navigation (GOTO, GOSUB etc) command.
/K=xxx : {+} Registered only. This switch places the
specified text <xxx> into the user's input buffer
to be processed exactly as if it had been entered
as a stacked command. This is an extremely powerful
facility which can be used to link a number of menu
commands together, and customise a large number of
hard-coded selection menus.
59
Menu templates
────────────────────────────────────────────────────────────
The biggest drawback of other BBS packages that allow the
sysop the flexibility of designing his or her own menus is
the amount of maintenance that is necessary in updating the
menus. Until now it was necessary to have a separate menu
for each file and message area. The RemoteAccess menu
templating system alleviates this problem by allowing you to
set up one menu that will act as a "skeleton" for all your
message and file areas. Two "variables" are available to
you; "M" for the currently selected message area and "F" for
the currently selected file area. In your template menu(s),
where you would normally put the message area number in the
optional data field for say a "Read" command, put in "/M".
When the read is selected by the user, RemoteAccess will
substitute this for a message area number. Likewise, where
you would specify a full path for a file function, put a "/F
in the optional data field. RemoteAccess will replace this
variable with the path to the currently selected file area.
To put a value into one of these two variables, simply put a
"/M=<Area Number>" or "/F=<Area Number>" in the optional
data field of a type 1, 2 or 4 menu command. For example,
say you set up a message area template menu called
"MSGMENU", using the /M in the optional data fields. Another
menu, which you have set up to list the available message
areas, simply consists of type 1 or 2 menu commands to jump
to MSGMENU. One menu line looks like this:
<H>ard Disk Conference
This is a type 2 command, which will "gosub" to the MSGMENU
menu:
Type : 2
On the optional data line, put the name of the menu to jump
to, and also set the template variable.
Optional Data : MSGMENU /M=45
45 corresponds to the hard disk conference area, as defined
in RACONFIG.
There are two other constructs that work with the template
commands. /M=+ or /F=+ will increment the currently selected
template area by one, and /M=- or /F=- will decrement the
currently selected template area by one. RemoteAccess will
automatically scan all file (or message) areas in the
specified direction to determine the next area that the user
has been given access to.
60
When RemoteAccess fires up, it scans both message and file
areas and sets each to the first area that the user has
access to.
There are a number of special characters that you can put in
the display line of a menu which will display certain system
information:
~ : Displays time remaining today.
^ : Switches between the normal line colours and the
overall menu highlight colours.
; : Don't display a carriage return / linefeed at the
end of the line.
@ : Displays the name (as defined in RACONFIG) of the
currently selected file template area.
` : Displays the name (as defined in RACONFIG) of the
currently selected message template area.
The global menu
────────────────────────────────────────────────────────────
It is likely that there are some commands that you will want
to be available from every menu that the user sees. Instead
of duplicating these for every single menu, simply place
them by themselves in a menu called GLOBALRA. RemoteAccess
searches for this special menu and if it exists,
automatically appends it to the end of every menu.
RemoteAccess appends the whole menu; in other words, not
just the commands but any visible text as well. Note that
the global menu will always inherit the highlight colours of
the current menu it is appended to. This feature is only
available in the registered version.
61
Setting up your menus
────────────────────────────────────────────────────────────
Spend some time thinking about how your menus will be set
up. Your BBS can be made to look as unique or as "uniform"
as you like - you can choose a subjective topology, where
the menus are organised according to area of interest, or a
functional topology, where menus are organised according to
their function. For example, a functional topology would
group all message areas together and all file areas
together, whereas a subjective topology would perhaps group
together several message and file areas that were related.
The diagram below illustrates this by depicting the same
systems using the two different topologies:
FUNCTIONAL
+----------Amiga messages
+---------Messages menu |
| +----------IBM messages
Main menu |
| +----------Amiga files
+------------Files menu |
+----------IBM files
SUBJECTIVE
+----------IBM files
+--------------IBM menu |
| +----------IBM messages
Main menu |
| +----------Amiga files
+------------Amiga menu |
+----------Amiga messages
Alternatively, you could even use a combination of the two
topology types.
The layout of your BBS is determined by how the menus are
set up. In many cases a user will not realise that he or she
is looking at a menu. The best technique for creating menus
is to create all the "low-level" menus first, then the main
menu, and then fill in between with the intermediate menus.
62
Creating your menus - RAMENU
────────────────────────────────────────────────────────────
Change to the system directory and fire up RAMENU.EXE; this
is the utility which allows you to create and edit your
menus. When run it will present you with a directory of
menus that have already been created - select one with the
cursor keys and press RETURN to edit, or simply press ESCAPE
to create a new menu.
A large window is opened that displays a line by line
summary of the menu. You may select a menu item to work on
by moving the hilight bar to the item with the cursor keys.
The following keys are available:
[RETURN] - Edit the currently selected menu item.
[INSERT] - Insert a new menu item immediately before the
current item.
[DELETE] - Delete the currently selected menu item.
[ALT-D] - Simulate what the menu would look like to a
user.
[ALT-P] - View or modify the menu prompt, its colour and
the menu highlight colours.
[ALT-S] - Save the current menu to disk.
[ALT-L] - Discard the present menu and load another from
disk.
Let's create the LOGOFF menu. Hit RETURN on the first blank
menu item to bring up the EDIT MENU ITEM window. The first
line of this menu will just display a message to the user,
so in the USER DISPLAY field, put "You have chosen to
disconnect. You may -". Move to the ACTION field and set it
to DISPLAY ONLY. Next select a suitable colour for the
display line in the COLOUR field. Since this is only a
display line, leave SECURITY and FLAGS as they are. Press
ESCAPE to return to the menu list, and note the entry you
have just created.
Now enter the user options for the menu. Move to the second
menu entry (add one with the INSERT key if necessary) and
press RETURN to edit. We'll give the user the option of
leaving a message to the sysop, so in the USER DISPLAY field
enter "<L>eave a message to the sysop". Set the ACTION to
POST A NEW MESSAGE (this is under the heading of MESSAGE-
BASE COMMANDS). This command requires a couple of parameters
in the optional data field - the number of the message area
to post the message in and the /T= parameter, to force the
message to be addressed to the sysop. It might look like
this:
63
80 /T=Andrew_Milner
(Message area 80 is set up as a "Messages to the sysop" area
that contains local private messages). Set the HOT-KEY to
"L" - this is the key that will activate the function. We
want all users to be able to leave a message, so set the
security level to 1.
The third line of the menu gives the user the option of
returning to the previous menu, so set this to a type 3,
with a suitable display line.
The actual log-off command is last. This will be a type 9
(Terminate Call). Set the hot-key to "G" and the display
line to something like "<G>oodbye (Logoff)".
The final step is to set the highlight and prompt options.
Press ALT-P from the menu list to bring up the EDIT MENU
SETTINGS window. Here you can tailor the menu by selecting
the menu prompt and its colour, along with the menu
highlight colour. Each menu line, in addition to it's own
colour, may contain an overall menu highlight colour. To
switch between the two colours on a menu line, simply insert
the ^ character; Note that this character isn't actually
displayed to the user, it just toggles the colours.
Experiment with this feature by inserting a few ^ characters
on display lines and viewing the menu with the ALT-D key.
Finally, save the menu by going back to the menu list and
pressing ALT-S. Save the menu with the name LOGOFF. Now,
whenever you need a "Goodbye" option in another menu, just
use a gosub (type 2) function to the menu LOGOFF.
There is one hard-coded menu called TOP. RemoteAccess
searches for this menu when a user logs on and displays it
first, so it MUST be present. The layout of the top menu is
up to you of course; it is recommended that you look at the
menus of other Bulletin Boards so you can incorporate their
best features into your own.
64
EXTERNAL SUPPORT FILES
────────────────────────────────────────────────────────────
There is very little that is actually "hard-coded" into
RemoteAccess. Below is a listing of text files you can place
in the text file directory to give your system just the
right "feel". See the section on TEXT FILE CONTROL CODES for
a list of special characters that can be used to display
system and user information from any of these files. Files
marked with an asterisk (*) have a default prompt if the
file is missing. All the files are plain ASCII which you can
create with your favourite text editor/wordprocessor, or
optionally ANSI which you will need a special ANSI editor to
create. See the section on TERMINAL EMULATIONS for further
information.
1ATATIME.A?? : This file is displayed if a user tries to
* log on to more than one line at once if
multi-line check has been enabled in
RACONFIG.
BADFILES.A?? : This file is displayed if the user attempts
* to upload a file that is listed in
BADFILES.CTL.
BIRTHDAY.A?? : This file is displayed if the current date
is the same as the user's birthdate.
DNLDHRS.A?? : This file is displayed if a user
* attempts a download outside the allowed
hours as defined in RACONFIG.
EDITHELP.A?? : This file is displayed if the user asks for
help while using the built-in message
editor.
ENDCHT.A?? : This file is displayed when the sysop
* terminates chat mode.
EXPIRED.A?? : This file is displayed if the user's
* password has just expired, just before the
user is asked for a new password.
FILEAREA.A?? : If present, this file will be displayed when
the user is asked to select a new file area
in place of the normal hard-coded list.
GOODBYE.A?? : This file is displayed when the user elects
to log off, just before the user is
disconnected.
HANDLE.A?? : This file is displayed just before the user
is asked to choose a new handle.
LOCKOUT.A?? : This file is displayed if the sysop uses
* ALT-L while a user is on-line to lock
him/her out of the system.
65
LOGO.ASC : This file is displayed as soon as a
connection is made. This should contain the
name of your system and perhaps some other
general information.
MAILHELP.A?? : This file is displayed if the user asks for
help at the mailbox scan prompt. Note that
the user is only offered help if this file
actually exists.
MAXPAGE.A?? : This file is displayed if a user tries to
* page the sysop for a chat more times than
you have specified in RACONFIG.
MSGAREA.A?? : If present, this file is displayed when the
user is asked to select a message area in
place of the normal hard-coded list.
NEWS.A?? : This file is a general news bulletin that is
displayed after RemoteAccess checks for
waiting mail (if the option is enabled), or
straight after the WELCOME file.
NEWUSER1.ASC : This file is displayed to a new user as soon
as he/she confirms that he/she entered
his/her name correctly.
NEWUSER2.A?? : This file is displayed after the user has
confirmed that he/she entered all the
standard logon questions correctly.
NO300.ASC : This file is displayed if a 300 baud caller
* attempts to log on during hours when 300
baud is not allowed, as defined in
RACONFIG.
NOCREDIT.A?? : This file is displayed if a caller attempts
* to enter a netmail message for which he/she
does not have sufficient credit.
NOTAVAIL.A?? : This file is displayed if a user tries to
* page the sysop for a chat outside paging
hours, as defined in RACONFIG.
NOTFOUND.ASC : This file is displayed if RemoteAccess
* cannot locate the name of a user at logon,
but before the user is asked to confirm that
he/she entered the name correctly.
NOTSYSOP.A?? : This file is displayed if a user attempts to
* post a message to "Sysop" in an EchoMail
message area.
ONCEONLY.A?? : This file is displayed just after the
NEWS.A?? file only once whenever the file is
altered.
66
ALTNEWS.A?? : This file is displayed ONLY if the NEWS.A??
file was not displayed to the user because
he/she requested to skip it during an IEMSI
session. If you want all users to see your
news file regardless, simply copy NEWS.A??
to ALTNEWS.A??.
PAGEABRT.A?? : This file is displayed if the sysop chooses
* to abort a page for chat by the user.
PAGED.A?? : This file is displayed after the user has
paged for a chat if the sysop does not
answer the page. Something like "Okay, the
sysop has been paged and will break in for a
chat if he/she walks past."
PASSWORD.A?? : This file is displayed before the user is
asked to select a new password. This file
should stress the importance of choosing a
suitable password!
PRIVATE.ASC : This file is displayed if a new user tries
* to log on to your system and you have set it
up as a private, pre-register BBS.
RATIO.A?? : This file is displayed if the user tries to
* do a download which would exceed his/her
ratio of number of files.
RATIOK.A?? : This file is displayed if the user tries to
* do a download which would exceed his/her
ratio of K of uploads to K of downloads.
READHELP.A?? : This file is displayed if the user asks for
help while reading messages.
SEC#.A?? : These files are displayed to users of a
particular security level directly after the
WELCOME file, but before the mail check (if
enabled). For example, the file
SEC10.ASC/ANS, if present, would be
displayed to all users with security level
10.
STARTCHT.A?? : This file is displayed when the sysop breaks
* in for a chat via ALT-C. Using the shell
from textfile function this could
conceivably be used to activate an external
chat utility. See also ENDCHT.A??
TIMEWARN.A?? : This file is displayed at log on if the
* user's time limit has been adjusted to
accomodate an upcoming event.
TODAYK.A?? : This file is displayed if the user attempts
* a download which would exceed his/her daily
download limit.
67
TOOSLOW.ASC : This file is displayed if a user tries to
* log on at a speed lower than the minimum
required to log on to your system as defined
in RACONFIG.
TRASHCAN.ASC : This file is displayed if a user enters an
* unacceptable name at log on, as listed in
the TRASHCAN.CTL file.
WELCOME.A?? : This file is displayed after the user logged
on, or in the case of a new user, after
completing the new user procedure. This can
be a fairly elaborate title screen that
welcomes your users to the BBS.
WELCOME1.A?? : This file is displayed directly after the
WELCOME file, and could contain extra system
information, maybe a "today in history"
quote, or something similar.
XFERHELP.A?? : This file is displayed if the user presses
the "?" key on the file transfer protocol
selection menu. It should contain general
information about the different protocols
themselves.
XFERTIME.A?? : This file is displayed if the user attempts
* a download that would exceed his/her daily
time limit.
In addition to these ASC/ANS files, there are a number of
*.CTL files that define various security aspects of the
system:
BADFILES.CTL : This file allows you to specify a list of
files that users may not upload. Simply
specify one file per line (wildcards valid),
for example:
*.GIF
NORTON*.*
Would not allow any files matching either of
these two patterns to be uploaded.
FILES.CTL : This file allows you to mark any
downloadable file on your system as free
and/or password protected. The format of
{+} this file is:
Registered
Only <filespec> [/FREE] [/PWD=xxx]
Example:
\RAFILES\RA_100.ZIP /FREE
\RABETAS\RABETA.ZIP /FREE /PWD=RACCESS
68
Note that each filename must be fully
qualified with a path (drive name optional).
Here, RA_100.ZIP is free. Downloading it
will not affect the user's download
statistics. Note that even though the file
is free in this regard, the user must still
have enough time remaining for the download.
RABETA.ZIP is both free and password
protected with the password RACCESS. The
user must supply the correct password before
being allowed to proceed with the download.
Passwords are case insensitive and a maximum
of 15 characters in length.
LIMITS.CTL : This file allows you specify, for each
security level, a daily time limit, file
download limit for each baud rate, and
optional file ratios, either in number of
uploads to number of downloads, or in total
kilobytes uploaded to total kilobytes
downloaded. The format of the file is as
follows:
<Sec Lvl> <Time> <300> [1200] [2400] [4800] [9600]
or:
<Sec Lvl> <Time> <300> <1200> <2400> <4800> <9600> <R#> [RK]
Where <Sec Lvl> is the security level,
<Time> is the daily time limit, <300> to
<9600> are respective download limits
depending on what baud rate the user calls
at. <R#> is the ratio of uploads to
downloads, and [RK] is the ratio of uploads
in K to downloads in K.
If you only specify a download limit for say
300, 1200 and 2400 baud, the download limits
for the higher baud rates default to the
highest baud rate specified, in this case
the limit set for 2400 baud.
If you specify a ratio by number (R#) value,
then the user will be required to upload one
file for every n they download. Similarly,
setting the ratio by K will allow the user
to download only the specified kilobytes of
files per 1 kilobyte uploaded.
This is fairly complicated, so look at this
example LIMITS.CTL:
5 35 0
10 60 100 200 350 650 900 5 10
20 90 150 250 470 750 900 5
30 120 250 400 600 900 1200
50 300 900
69
Security level 5 entitles the user to 35
minutes per day, but no downloads.
Security level 10 entitles the user to 60
minutes per day, 100k of downloads at 300
baud, 200k at 1200 baud, 350k at 2400 baud,
650k at 4800 baud, and 900k at 9600 baud or
faster. In addition, the user must upload at
least one file for every five downloaded,
and may not download more than ten times the
total size of files uploaded.
Security level 20 entitles the user to 90
minutes per day, 150k of downloads at 300
baud, 250k at 1200 baud, 470k at 2400 baud,
750k at 4800 baud and 900k at 9600 baud or
faster. In addition, the user may only
download five times the number of files
he/she uploaded.
Security level 30 entitles the user to 120
minutes per day, 250k of downloads at 300
baud, 400k at 1200 baud, 600k at 2400 baud,
900k at 4800 baud and 1,200k at 9600 baud or
faster. There are no ratio restrictions.
Security level 50 entitles the user to 300
minutes per day, and 900k of downloads at
all speeds without any ratio restrictions.
NAMES.RA RemoteAccess allows you to assign
"shortnames" to users you frequently send
messages to. Set up this text file with the
following format, one entry per line:
<shortname>,<realname>,<address>[,<subject>]
Eg:
rahq,Andrew Milner,3:690/625,RemoteAccess..
To use this feature, simply enter the
shortname preceded by an asterisk when
RemoteAccess asks you who the message is to.
In the above example, addressing a message
to "*rahq" would fill in the to field with
"Andrew Milner", and the subject field with
"RemoteAccess..". If the message is netmail,
it would automatically be sent to 3:690/625.
PHONENUM.CTL : Use this file to specify phone numbers or
segments of phone numbers that you know
to be false. A PHONENUM.CTL that contains:
00-
000-
-0000
70
Would disallow the numbers "00-123-4567",
"000-123-4567", "009-0000-1234". The rule
here is that none of the specified numbers
is allowed to be imbedded anywhere in the
user's phone number.
PWDTRASH.CTL : Allows you to specify a list of passwords
that users are not allowed to use. This
could contain passwords like SECRET, or
TEST.
TRASHCAN.CTL : Allows you specify a list of names that
users may not use to log on to your system.
In this file, specify the undesirable names
one per line. If for example you did not
want the names "Sysop", "Jack Daniels" or
"Superman" used, simply put the following
lines in this file:
Sysop
Jack Daniels
Superman
The tests done on names is NOT case-
sensitive, so the name "SYSOP" would also be
invalid. Names that contain any part of the
names in the list are not allowed either.
71
THE USER DATABASE
────────────────────────────────────────────────────────────
The user file is possibly the most important single file on
your BBS. It contains all the information about each user's
history, screen settings, and vital security data. Switch to
your system directory and fire up USERED.EXE. This
utility allows you to add, modify or delete any user's
record. If there are already some users in the user-file,
you will be presented with a list showing each user's name,
location and security level. Select a user either by typing
in the name, or moving the highlight bar to the entry on the
screen and pressing RETURN.
After the user is selected you will be presented with the
Edit Screen. This lists the entire user's record which can
be modified and saved if you wish.
If there are no users already in the user-file, the Edit
Screen will appear immediately for you to enter the details
of the first user. Note that the only required piece of
information (or "field") is the name, and you can't proceed
any further until you enter one. You'll want to be included
in the user file, so enter your own name in this field.
Next, go through each of the other fields and enter the
correct details. When finished, press [CONTROL-ENTER] to
save the information and then ESCAPE to exit. If you don't
want to save, just press ESCAPE by itself.
To add a new user, simply press the INS key on the user list
screen and a blank record will be created for you to edit.
Deleting a user is accomplished by moving the highlight bar
to the user you want to delete and pressing the DEL key. A
marker will appear in the right hand column to signify that
the user is marked for deletion. Note that the user isn't
actually removed from the user file at this stage. Users
that have been marked for deletion are removed by packing
the user-file, which should be done regularly using the
utility RAUSER.
72
Information stored in the user database
────────────────────────────────────────────────────────────
This section details all the information contained about
each user in the user database:
Name : User's full name
Handle : User's registered handle
Location : Where the user is calling from
Password : Secret password
Security level : Security level (1-64000, 0 to lock out)
Home telephone : Home/voice telephone number
Business telephone : Business/data telephone number
A flags : "A" flag settings ("-" or "X")
B flags : "B" flag settings ("-" or "X")
C flags : "C" flag settings ("-" or "X")
D flags : "D" flag settings ("-" or "X")
Netmail credit : Netmail credit remaining
Unsent netmail : Value of unsent (unexported) netmail
Uploads : Total number of uploads
Downloads : Total number of downloads
Upload K : Total kilobytes of uploads
Download K : Total kilobytes of downloads
Today download K : Kilobytes downloaded today
Comment : Comment, can contain anything
Last call (time) : Time user last called
Last call (date) : Date user last called
Subscription : Subscription expiry date
Birthdate : Date of birth
Time used : Minutes used today
Screen length : User's screen length
Password calls : Number of calls since last pwd change
Msgs posted : Total number of messages posted
High msg : Highest message read
Deleted : Delete user when database is packed?
Screen clear : Send screen clear codes?
Screen pause : Pause at the end of each screen?
ANSI : Send ANSI codes?
AVATAR : Send AVATAR codes?
Locked : Never kill user?
Xfer priority : Ignore download hours and ratios?
Full screen editor : Use the full screen ANSI msg editor?
Quiet mode : Ignore online messages?
Hotkeys : Use hotkeys?
Full screen viewer : Use the full screen msg viewer?
Hidden : Hidden from the user list?
Group number : User's group number (1 - 255)
73
Packing and sorting the user file
────────────────────────────────────────────────────────────
RAUSER.EXE is the utility that is used to maintain the user-
file. Not only will it remove users marked for deletion, it
can also delete users that have not called your BBS for a
certain number of days as well as sort the users in order of
security level and surname. RAUSER may be run from any
directory, will automatically locate system and user files,
and will insert an activity summary in your system log. The
following command-line parameters are valid:
-P Pack the user-file, removing users marked for
deletion.
-S Sort users in order of security level and
surname.
-D[n] Delete users who have not called for [n] days.
Note that this parameter implies a pack
operation.
-V Verbose logging; list any users that were
deleted during a pack operation.
-M[s] Specify the maximum security level user to be
affected by a pack or delete operation. Put
another way : "exempt all users with security
level [s] and above from being deleted" .
74
THE MESSAGE DATABASE
────────────────────────────────────────────────────────────
RAMSG is the RemoteAccess message base maintenance utility.
It's primary function is to trim the number of messages in
local and echomail conferences and maintain them at a
manageable level. RACONFIG provides the ability to enter,
add and maintain message areas - RAMSG uses this
information (contained in MESSAGES.RA) to delete old and/or
excess messages. RAMSG will also attempt to repair
damaged message bases; it has a number of integrity checks
built in so that if it detects that the message base is
damaged in any way, it will automatically re-create index
files (even if they are missing) and warn of possible
problems.
All of RAMSG's activities are logged in the system log.
Some options are provided for statistical information.
Note that a value of 0 in any of the fields on the message
area entry screen in RACONFIG will cause RAMSG to ignore
that option. For example, if the maximum number of messages
is set to 0, RAMSG will not kill messages based on number.
Prior running RAMSG, you should ensure that all areas have
been set up correctly.
RAMSG invoked without a command line results in a help
screen being displayed.
When one or more of the arguments below is specified, RAMSG
searches for CONFIG.RA (first the current directory, then
via the RA environment variable), MESSAGES.RA (in the
current directory, then the system directory) and then the
message base files. Failure to find one or more of these
files will result in RAMSG aborting. If CONFIG.RA is found
and the system log file can be opened, RAMSG will log any
errors there.
Message database size limitations
────────────────────────────────────────────────────────────
Due to the message database file structures, there is a
maximum physical limit on the number of messages it can
contain. The maximum number of messages the database can
hold is approximately 16,000. You should configure RAMSG so
that this limit is never exceeded.
There is also a limitation on the value of the highest
numbered message, which may never exceed 32,767. It is good
practice to regularly (preferably nightly) renumber the
message database to ensure that this limit is never
breached.
75
RAMSG Command summary
---------------------
-I Re-create index files & check
C=Kill crosslinked messages
U=Kill unknown boards
R=Renumber
-P Pack (compress) message base
K=Purge
R=Renumber
O=Overwrite
A=Overwrite if necessary
-K Purge messages from info in MESSAGES.RA
-L Link reply chains
-R Renumber messages
-S Display/log message base statistics
All options: S=Statistics V=Verbose stats
RAMSG functions (NOT case sensitive)
------------------------------------
-I INDEX [Options : C, R, U]
This option rebuilds the message base
index files, MSGIDX.BBS, MSGTOIDX.BBS and
MSGINFO.BBS. It also checks the integrity
of all message base files and rebuilds other
information as necessary. Errors in the
message base are logged.
During the index rebuild, you may
choose to delete messages from unknown
message areas (those areas which have no
entry in the name field) and messages with
message board numbers outside the valid
range of 1-200.
Under some circumstances RAMSG may
detect a "sequence error" (when numbers are
out of order). Since this causes
significant problems with software using the
message base, RAMSG considers this serious,
and therefore will not proceed with any
operation other than an index rebuild
until this is corrected using the "R"
option, to force message base renumbering.
76
"Crosslinking" of message text is also
considered a serious problem, and this will
prevent RAMSG repacking the message base.
Cross-linking occurs when more than one
message references the same section of
text in MSGTXT.BBS.
Following are some examples of what an
index rebuild command might look like:
RAMSG -Icu
Rebuild indices, kill messages in unknown
areas and crosslinked messages.
RAMSG -I
Rebuild index files only.
-P PACK [options : K, R, O, A]
Packs the message base, by eliminating
all deleted messages and message text.
Deleting (the -K option, for example)
messages does not remove them from the
message base files, it simply marks them for
deletion. You MUST pack the message base
to reclaim the space occupied by these
deleted messages.
PACK also provides options to purge
old/excess messages (same as -K, except
that -K does not pack) and renumber
(same as -R), so all standard
maintenance functions can be carried out in
the one command.
RAMSG normally packs the message base by
copying messages from the existing
message base into temporary files,
deleting the original files, then
renaming the temporary files to their
correct names. This is the safest option to
use, since it is possible to rebuild the
message base if for any reason the PACK
process is interrupted (for example, by
power failure). However, this requires that
at least as much space as occupied by the
old message base files be free on your hard
disk.
77
To get around this, RAMSG provides an
option to pack the message base "on top" of
the existing one without using temporary
files. This directly overwrites the
existing files; and the problem with this is
that if the process is interrupted, the
message base may be irreparably damaged
and data could be lost. To use overwrite
mode, RAMSG requires the 'o' option in the
PACK command; this forces overwriting
unconditionally. To ensure that the message
base is processed, while taking advantage
of a safer environment, RAMSG also
provides an 'a' option, which will use
overwrite mode only if there is insufficient
space for a regular pack.
Examples:
RAMSG -Pkra
Pack the message base, kill messages
according to information in MESSAGES.RA,
renumber messages and use overwrite mode
only if insufficient disk space for a
regular pack.
RAMSG -Po
Pack the message base, using overwrite mode.
-K Purge messages
This option purges messages according to
the maximum number of messages and aging
information specified for each area in
MESSAGES.RA. Note that the messages are not
actually removed, they are simply marked for
deletion. Use the pack command to reclaim
the space that these messages occupy.
-L Link reply chains
Links reply chains in each area (this
is automatically done by other maintenance
functions where necessary). You would use
this option by itself after an import by
your echomail processor, for example.
-R Renumber messages
Renumbers the message base. This option may
also be used to cure "out of sequence"
errors.
78
-S Display/log message base statistics
Simply logs message base and disk statistics
for your own information. A 'v' after this
option displays verbose statistics for each
message area.
You may run several operations on the same command line,
but since there is some overlap in functionality, the need
to do this is rare. One instance of where you might need
this facility is to force the message base to be "clean"
prior running a pack; for example:
RAMSG -Icur -Pkra
Checks/rebuilds index files, deleting messages in unknown
areas, fixes cross-linked messages and forces a renumber
to fix sequence errors. It then will proceed to pack and
renumber the message base after killing excess/expired
messages using overwrite mode if required.
Several errorlevel exits are provided to allow management
by batch file:
1 No arguments specified; help message given.
2 Cannot access/locate CONFIG.RA
3 Out of or insufficient memory
4 Error opening/locating a file
5 Serious IO error
79
MAIL NETWORKING
────────────────────────────────────────────────────────────
What is a mail network? Basically it is a set of bulletin
board systems that are capable of exchanging messages and
files with each other without the need for human
intervention. All the discussion which follows relates to
FidoNet, the world's largest amateur mail network. FidoNet
consists of approximately 5,000 bulletin board systems, each
of which is assigned a unique "address". A file called a
nodelist stores all these addresses along with other
information about each system. Think of it like an
international "telephone book".
Being part of a network has two basic attractions; NetMail
and EchoMail. NetMail allows you to send a private message
to any user of any one of the bulletins boards in the
network at little or no cost to you. EchoMail is a method of
creating a huge message area that many hundreds of systems
can potentially participate in. Usually all EchoMail areas
will contain only public messages, and are organised into
either general discussion areas, or areas that deal with
specific issues and or topics.
The net is organised into several levels, which are usually
based on geographical proximity. At the highest level there
are five "zones"; zone 1 is the USA, zone 2 is Europe, zone
3 is the Pacific Rim, zone 4 is South America, zone 5 is
Africa and zone 6 is Asia. Within each zone are a number of
"regions" that span large geographical areas. Typically
there will be between 5 and 18 regions per zone. Each region
is further divided into "nets". Each net has a unique
net number, and the distribution of these nets is also
based on geographical and technical considerations.
Finally, within the net are a number of nodes. A node
refers to a single bulletin board system.
To find out about obtaining a node number, or an "address",
contact the nearest FidoNet bulletin board. The sysop will
usually be more than happy to help you out.
Before going any further, let's talk about the extra
software you will need to set up as a node. Firstly you will
need an echomail processor. This is the program which
unpacks the mail you will receive, and imports it into your
RemoteAccess message-base, as well as packing up outbound
mail that needs to be sent out. RemoteAccess does NOT
include such a beast. There are several other processors
around that will do the job:
Echogen and QEcho, both by Adam Hudson,
ZMailH, by Claude N. Warren,
TosScan, by Joaquim Homrighausen,
IMAIL, by Fabiano Fabris.
80
The other piece of software you'll need is a mailer.
RemoteAccess will not directly communicate with other
network bulletin boards, so a separate program fills the
gap. The two most widely used different types of mailers
are:
FrontDoor, by Joaquim Homrighausen,
BinkleyTerm, by Bit Bucket Software.
Both of these products are available on a shareware basis,
and like the echomail processors, will usually be
available on most FidoNet bulletin boards if you ask the
sysop nicely enough.
The node number you are assigned will be of the format
Zone:Net/Node.Point. This initial node number should be put
into your configuration file using the ADDRESS option of
RACONFIG. Don't worry about the AKA addresses at this stage.
The next step is to set up your EchoMail message areas. You
will usually be given a list of areas that are available to
you. Each area is identified by an uppercase alphanumeric
name. As far as RemoteAccess is concerned, all you need is a
description of each area you plan to "plug into". Fire up
RACONFIG, and go to the MESSAGE AREAS window. Select an
unused message area, and enter the area's name in the NAME
field. Next, set the TYPE OF MAIL field to ECHOMAIL, and
MESSAGE STATUS to PUBLIC. Most EchoMail areas don't allow
the use of aliases, so set the area to "real names only".
The AKA ADDRESS line shows your assigned node number. If
it doesn't, hit RETURN on this option and select the
correct address.
Each EchoMail message that is posted on your system could
potentially be read by hundred of other sysops and users, so
you can put a "one-liner" at the end of each message. In the
ORIGIN LINE field enter a short message. This should contain
at least the name of your system, and possibly where it is
or the phone-number, so that other users know where to call.
Your node number is also appended to the end of the message,
so a typical origin line might read:
* Origin : RemoteAccess HQ (3:690/625.0)
Don't put the "* Origin" part in - this is added by the
software). If you don't specify an origin line for a
particular area, RemoteAccess will use the DEFAULT ORIGIN
LINE.
If running a multi-node system, the line number that the
message was posted on may be inserted in the origin line by
using the '@' macro character in any origin line definition.
81
The next step is to configure RemoteAccess for NetMail.
Select another unused message area, and call it "NetMail",
or something similar. Next, set the TYPE OF MAIL to NETMAIL,
and MESSAGE STATUS to PRIVATE. NetMail messages don't have
origin lines appended to them so leave the origin line entry
blank. RemoteAccess incorporates a comprehensive online
nodelist browsing facility, which allows users to search for
nodes in particular zones, regions or nets. The section
INSTALLING NODELIST FILES explains how to enable this
feature.
That's it! RemoteAccess is now fully configured for network
mail. Assuming that you have a suitable mailer and echomail
processor, all that is required is to set them up correctly
and you're in business. An explanation of setting these up
is beyond the scope of this document, full instructions are
available with each respective package.
82
Installing the nodelist files
────────────────────────────────────────────────────────────
Most other BBS software requires you to maintain large and
unwieldy custom nodelist files for NetMail operation.
RemoteAccess uses the "raw" (St. Louis) nodelist that you
already have for your front-end mailer, in addition to a
small (around 5K) index file. The key to the system is the
nodelist index compiler (RANODE.EXE). You should adjust your
batch files so it is run every time any changes are made to
your raw nodelist (when you receive a NODEDIFF update, for
example). RANODE can be run from any directory, and locates
your raw nodelist via the NODELIST PATH defined in RACONFIG.
It scans the most recent nodelist present and produces the
index files (NODEIDX.RA and NODEINC.RA) in your
RemoteAccess system directory. If you have multiple
nodelists to process, simply specify the names of any
additional nodelists on the command-line when RANODE is
executed.
Example : Compiling a FidoNet nodelist only. The raw
nodelist is in the C:\NODELIST directory. Simply set your
NODELIST PATH in RACONFIG to C:\NODELIST, and run RANODE
whenever you process a nodediff, without any command-line
parameters.
Example : Compiling a FidoNet and ParaNet combined nodelist.
The FidoNet NODELIST.nnn and ParaNet PARALIST.PVT raw
nodelist files are in C:\NODELIST. Simply run RANODE with
the following parameter:
RANODE PARALIST.PVT
Up to ten nodelists (including the FidoNet one) may be
specified - wildcards and pattern matching characters are
valid.
Note that it is not necessary to specify the FidoNet
NODELIST.nnn as well, as RANODE includes the most recent
FidoNet nodelist automatically.
In order to control the volume of netmail your users send,
each user has a "netmail credit" field in his or her record.
RemoteAccess will give all new users a credit limit
based on the NEW USER NETMAIL CREDIT setting in RACONFIG.
You define the cost of sending a single message to a
particular node in a control file called NODECOST.CTL which
is located in the RemoteAccess system directory. Each time a
user sends a netmail message, it's cost is deducted from his
or her account.
The cost structure for your entire nodelist is set up by one
or more entries of five keywords:
83
DEFAULT <cost>
Assigns <cost> to any nodes that are not assigned a specific
cost later on in the control file.
ZONE <zone> <cost>
Assigns <cost> to all nodes in <zone>. This overrides the
DEFAULT keyword.
REGION <region> <cost>
Assigns <cost> to all nodes in <region>. This overrides the
DEFAULT and ZONE keywords.
NET <net> <cost>
Assigns <cost> to all nodes in <net>. This overrides the
DEFAULT, ZONE and REGION keywords.
NODE <node> <cost>
Assigns <cost> to <node>. <Node> is a fully qualified node
address. This overrides all other keywords.
Sample NODECOST.CTL:
DEFAULT 200 ; A message to anywhere costs 200 cents,
ZONE 3 60 ; except in zone 3, which costs 60 cents.
ZONE 2 260 ; Messages to zone 2 cost a bit more,
REGION 55 30 ; Within our region only costs 30 cents.
NET 690 0 ; Msgs within our net are free,
NODE 690/999 5 ; except this node which isn't local.
The control file may contain a maximum of 150 entries of
each keyword, and duplicate entries are obviously not
permitted.
84
MULTI - NODE OPERATION
────────────────────────────────────────────────────────────
It is assumed that you have some knowledge of running
RemoteAccess already, or have at least run a single line BBS
for some time. If you haven't, it is strongly recommended
that you run one line for a little while to familiarise
yourself with the terminology and operation of RemoteAccess.
The idea of multi-node operation is that more than one user
can be on-line at the same time to the same BBS. To do this
safely, it is necessary for RemoteAccess to manage the
configuration and data files it uses very carefully.
Firstly, tell RemoteAccess that it's running in multi-node
mode by setting the MULTI LINE option to "Yes" in RACONFIG.
You should also set CHECK FOR MULTI LOGON to "Yes". Not
doing this can cause unpredictable results when a user logs
on to more than one line at once.
Set the SYSTEM LOG NAME to "RA.LOG". Make sure you do NOT
specify a full path with the name.
Next create one child directory of your system directory for
each line you intend to operate. For example, assuming that
the system directory is C:\RA, for two lines create
C:\RA\LINE1 and C:\RA\LINE2 (the actual directory names are
not important).
At this stage, ensure that the RA environment variable
points to the system directory so each line will be able to
locate the configuration files.
Why separate directories? Many on-line utilities and doors
are not multi-node aware, so they must be isolated from
themselves in the event that more than one copy of the same
door is executed at the same time. Thus it may be necessary
to place extra configuration files for some doors in each
line directory.
For example, to install QuickEd in a multi-node environment,
ensure that QUICKED.EXE is in the system directory (C:\RA in
this example) and that the EXTERNAL EDITOR setting in
RACONFIG is set to "C:\RA\QUICKED.EXE". To complete the
installation, copy the files QUICKED.HLP and QUICKED.CFG
into each line directory; these two files need not be
present in the system directory.
All that is necessary now is to create the batch files that
call each copy of RA for each line:
REM Sample batch file to fire up line 1
:START
CD \RA\LINE1
RA -N1
REM Check errorlevels etc
GOTO START
85
Note that the -N1 parameter is not required since
RemoteAccess defaults to line 1; it is included only for
completeness.
REM Sample batch file to fire up line 2, using FrontDoor
REM as a front-end mailer in shell to mailer mode
:START
CD \RA\LINE2
RA -M\FD\FD.EXE*M -N2
REM Check errorlevels etc
GOTO START
RemoteAccess will keep a separate system log (RA.LOG) and
usage graph file (TIMELOG.BBS) in each line directory.
The placement of the EXITINFO.BBS and DORINFO1.DEF door
files is handled differently in a multi-node environment. In
a single line installation these files are written to the
RemoteAccess system directory. In multi-node mode they are
written to the current (default) directory, thus ensuring
that each door has it's own set of info files from the BBS
at all times.
Additional configuration flexibility is provided in the
method RemoteAccess uses to locate the configuration (*.RA)
files. If one or more of the *.RA config files is present in
a particular line directory, then the information in those
files will override the information contained in the
corresponding config file in the system directory.
For example, it may be necessary for each line to use
different modem configuration information. This data is
contained in CONFIG.RA, so make a copy of this file in each
line directory. Change to the line 1 directory and use
RACONFIG to edit the modem settings. Save your changes and
repeat the procedure for line 2. When RemoteAccess fires up,
it will use the CONFIG.RA in the current directory that you
just edited, and the other config files in the system
directory.
The LIMITS.CTL file works in the same way; you may override
the global settings in the system directory by making a copy
of LIMITS.CTL in one or more line directories and editing
with an ASCII text editor. This enables each line to exhibit
different download and time limits for one particular
security level.
Beware of third party utilities that write to the system
files! RemoteAccess is specifically written so that many
users can read and post messages simultaneously to the same
message-base, but other programs probably AREN'T. Check the
documentation very carefully before you fire up your
favourite off-line mail editor and start posting messages
while someone else is on-line. Similarly, if your echomail
processor does not lock the message-base files while
working, you should set up your system to ensure that mail
is never imported when there is a user on-line. Exporting
messages however, IS permitted.
86
It's quite likely that you'll need to increase the FILES
setting in your CONFIG.SYS if RemoteAccess is running
several lines under a multitasker. You'll also need a
separate batch-file for each line to invoke RemoteAccess
with the correct command-line parameters. See the reference
section on command-line parameters for information on the -N
parameter.
It is ESSENTIAL that you load SHARE.EXE when operating
multi-node. SHARE is a utility that comes with DOS which
RemoteAccess uses to lock the database files it uses, to
ensure that no conflicts occur. Not using SHARE is asking
for trouble; you risk severe corruption of both your user
and message database files.
87
REFERENCE SECTION
────────────────────────────────────────────────────────────
Sysop keys
────────────────────────────────────────────────────────────
The following keys work while a user is on-line:
[F1] [F2] : Comprehensive user statistics on an optional
[F3] [F5] two-line status bar at the bottom of the
screen.
[F4] : System statistics. This is the default status
bar that is displayed when RemoteAccess is
waiting for a call.
[F6] : User's reason for wanting chat (if any).
[F7] : Interactive EMSI session information.
[F9] : Help! Hot-key summary.
[F10] : Turn off the status bar, to show exactly what
the user is seeing. [F1] to [F5] brings it
back.
[ALT-Fn] : Activate one of ten programs in a shell, or
exit to DOS at a certain errorlevel.
[ALT-C] : Break in for a chat if there is a user on
remotely. ESC finishes chat mode and drops
the user back to the BBS.
[CTL-A] : Opens and closes a capture file during a
chat session.
[ALT-D] : Toggles "Snoop" mode, ie. whether the local
screen shows what the user is doing.
[ALT-E] : Activates a pop-up user attribute editor
for the user currently online.
[ALT-H] : Hang up on the user immediately.
[ALT-J] : Drop to a DOS shell while the user is still
on-line.
[ALT-L] : Lock the user out of the system by dropping
his/her security level to zero and hanging
up.
[ALT-N] : Toggle "sysop on next". When this mode is
activated (indicated by [NS] on the F1 status
bar), RemoteAccess will pause and page the
sysop for two minutes when the current user
logs off. {+} Registered only.
88
[ALT-P] : Toggle printer logging.
[ALT-O] : Override paging hours. This allows you to
enable or disable sysop paging regardless of
the time. Note that this is permanent, and
affects all lines until reset.
[ALT-S] : Modify the current user's security level.
[Up-Arrow] : Increase the user's time by one minute.
[Down-Arrow] : Decrease the user's time by one minute.
When the system is waiting for a call, the only sysop key
that is active is [ALT-O], however, pressing [L] will allow
you to log-on locally, and [ESC] will terminate the program
and return to DOS. Note that terminating in this way will
always return an errorlevel of 0 to DOS regardless of
whether the -E command-line parameter is invoked.
89
Command-line parameters
────────────────────────────────────────────────────────────
RemoteAccess accepts the following command-line parameters:
-NOEMS : Forces RemoteAccess to ignore any available EMS.
-Kpwd : Lock the local keyboard with a password. The
{+} password must be correctly entered prior to using
any ALT-key.
-L : Run RemoteAccess in local mode.
-S : Set "snoop" mode off; disable local screen.
-D : Disable status bar by default.
-R : Log user back on-line after a menu type 15 exit.
-G : Used with the -R option; forces RemoteAccess to
{+} return to the last menu the user was in at the
time of the previous exit to DOS. The default is
to return to the TOP menu.
-P : Log user activity to printer.
-Nxx : Line (node) number in a multi-line system (1-99).
-Cx : Communications port to use (1-4).
-Bxxxxx : Log user on-line at baudrate xxxxx.
-Exxx : Exit at errorlevel xxx after caller logs off.
-Txxx : Time (in minutes) until next system event.
NOTE: Some mailers have the capability to generate
a "standard format" batch file called DOBBS.BAT to
run the BBS program. In shell-to-mailer mode (see
below) RemoteAccess will scan this batch file (if
present) to determine the time until the next
event.
-M<f> : Activate the "shell to mailer" feature. This
causes RemoteAccess, upon loading, to execute your
front-end mailer program in a DOS shell. When the
mailer exits, RemoteAccess detects the errorlevel
it would normally pass to the batch-file. If the
errorlevel matches one defined in RACONFIG, the
user is logged on to the BBS at the appropriate
baud rate. If the errorlevel is not recognised as
an incoming call, RemoteAccess exits to its
batch-file at that errorlevel. See the BATCH FILE
EXAMPLES section for more on this feature.
NOTE: RemoteAccess does the swap by storing a
"swap file" in EMS (if available) and on disk.
Normally this file would be stored in the system
directory, but it is possible to force
RemoteAccess to put the file in a directory of
your choice by setting the RATEMP environment
variable. For example, if you executed the DOS
command SET RATEMP=E:\TEMP\STORAGE, then the swap
file would be placed in the E:\TEMP\STORAGE
directory.
90
In "shell to mailer" mode, it is possible for two
errorlevels to conflict. For example, errorlevel 5
is used by RA to indicate that a user entered both
net and echomail, and by FrontDoor to indicate
modem initialise failure. If the front-end returns
an errorlevel that conflicts in this way,
RemoteAccess will pass to the batch file that
errorlevel plus 10. So, if FrontDoor returned
errorlevel 5 because the modem would not
initialise, RemoteAccess would pass errorlevel 15
to the batch file.
91
Errorlevels
────────────────────────────────────────────────────────────
When RemoteAccess exits to DOS either after a user logs off
or because of a menu type 15 "Exit to DOS" function it
returns an errorlevel that your batchfile should test for
and act on accordingly:
Errorlevel Meaning
---------- -------
0 User logged off OK, default value. Note - this
can be overridden with the -E command line
parameter.
1 Initialisation error - couldn't find the FOSSIL
driver, or the modem failed to initialise.
2 Special error condition; used for Beta versions
only.
3 The user entered one or more NetMail messages
during the session. The message base should be
scanned for outgoing NetMail.
4 The user entered one or more EchoMail messages
during the session. The message base should be
scanned for outgoing EchoMail.
5 Both NetMail AND EchoMail messages were entered.
92
Text file control codes
────────────────────────────────────────────────────────────
There are a range of special control characters that can be
inserted in any of your ASCII/ANSI files that cause certain
system and user information to be displayed. There are three
classes of codes. Each code is a two-character combination
of a control-code followed by by a normal character:
Character
ASCII# Combination Purpose
------ ----------- --------------------------------------
01 ^A Wait until the [Return] key is pressed
02 ^B Disable aborting with the "S" key
03 ^C Enable aborting with the "S" key
04 ^D Enable the "Continue?" prompt
05 ^E Disable the "Continue?" prompt
06 ^F * Insert a user parameter
07 ^G Produce a beep on the caller's console
08 ^H Backspace
09 ^I Tab (forward 8 characters)
10 ^J Linefeed
11 ^K * Insert a system parameter
12 ^L Clear screen
13 ^M Carriage return
17 ^Q RESERVED FOR XON/XOFF HANDSHAKING
19 ^S RESERVED FOR XON/XOFF HANDSHAKING
22 ^V RESERVED FOR AVATAR
23 ^W Pause for one second
24 ^X * Execute a program in a DOS shell
26 ^Z END OF FILE MARKER. DON'T USE THIS!
EXECUTING A PROGRAM IN A DOS SHELL:
This gives you the ability to run an external program in a
DOS shell whenever RemoteAccess encounters a ^X embedded in
a text file. The ^X is followed by the command line you want
to execute, and terminated with the pipe symbol (|). For
example, to run an external mail checking utility when a
user logs on you could embed the following entry in the
WELCOME.A?? file:
^X\RA\MAILCHEK.EXE *B *F *L|
RemoteAccess would then execute the following DOS command:
\RA\MAILCHEK.EXE 2400 FirstName LastName
Note that you MUST terminate the command with the pipe
symbol. All special DOS shell control codes may be used as
per the type 7 menu function.
BEWARE! Use this feature with caution. Imagine the damage
that this embedded command could do:
COPY \RA\USERS.BBS \RA\FILES\IBM\NEWFILES
93
If there is any possibility of a user being able to modify
any of the text files that your system displays, then
disable the shell feature by using the option in RACONFIG.
"Note to next user" programs are notorious for this! If you
don't think it ever happens, then maybe this will convince
you. A local sysop was watching his board one afternoon and
noticed that when a user logged off, he got the following
message:
"Hey, Joe! What sort of a password is ROCKET? Next time
choose a harder one!! ... Fred"
The sysop couldn't believe his eyes. How could this have
happened? Well, the "note to next user" utility he had
installed a few weeks earlier was to blame. It actually
allowed a user upload a short text file that was appended to
the GOODBYE disconnect file. "Fred" had simply inserted a
few control characters into the file that would display the
current user's first name and password, which of course
would always be correct for whoever viewed it. Well, it
shook that sysop up a bit, as well as teaching him a lesson.
Luckily the ^X feature wasn't enabled, or anything could
have happened...
94
* User Parameter Codes
----------------------
Character
ASCII# Combination Information displayed
------ ----------- ---------------------------------------
65 ^FA Users full name
66 ^FB Location
67 ^FC Password
68 ^FD Business/Data phone number
69 ^FE Voice/Home phone number
70 ^FF Date of last call
71 ^FG Time of last call
72 ^FH A Flags setting
73 ^FI B Flags setting
74 ^FJ C Flags setting
75 ^FK D Flags setting
76 ^FL NetMail credit remaining (cents)
77 ^FM Total messages posted
78 ^FN Last message read
79 ^FO Security level
80 ^FP Total calls to the BBS
81 ^FQ Number of uploads
82 ^FR Kilobytes of uploads
83 ^FS Number of downloads
84 ^FT Kilobytes of downloads
85 ^FU Minutes used today
86 ^FV Current screen length
87 ^FW First name only
88 ^FX ANSI setting (ON/OFF)
89 ^FY "Continue?" prompt setting (ON/OFF)
90 ^FZ Screen clearing (ON/OFF)
48 ^F0 Full screen editor (ON/OFF)
49 ^F1 Quiet/do not disturb mode (ON/OFF)
50 ^F2 Hot-Keys (ON/OFF)
51 ^F3 Handle
52 ^F4 Date of first call
53 ^F5 Date of birth
54 ^F6 Subscription expiry date
55 ^F7 Days until subscription expiry
56 ^F8 AVATAR setting (ON/OFF)
57 ^F9 File ratio (number of files)
58 ^F: File ratio (kilobytes)
59 ^F; Full screen message viewer (ON/OFF)
95
* System Parameter Codes
------------------------
Character
ASCII# Combination Information displayed
------ ----------- ---------------------------------------
65 ^KA Total system calls
66 ^KB Last caller (any line)
67 ^KC Number of active messages
68 ^KD System starting message number
69 ^KE System ending message number
70 ^KF Number of times user has paged sysop
71 ^KG Day of the week (full form)
72 ^KH Number of users in the user file
73 ^KI Time in 24 hour format
74 ^KJ Today's date
75 ^KK Minutes connected this call
76 ^KL Seconds connected (always returns 0)
77 ^KM Minutes used today
78 ^KN Seconds used today (always returns 0)
79 ^KO Minutes remaining today
80 ^KP Seconds remaining today (always 0)
81 ^KQ Daily time limit
82 ^KR Current baud rate
83 ^KS Day of the week (abbreviated form)
84 ^KT Daily download limit (in K)
85 ^KU Minutes until next system event
86 ^KV 24 hour format time of the next event
87 ^KW Line number (as set on command line)
88 ^KX TERMINATES THE CALL
89 ^KY Name of current template message area
90 ^KZ Name of current template file area
48 ^K0 Number of msgs in selected msg area
49 ^K1 Number of current template message area
50 ^K2 Number of current template file area
96
Modem string translation
────────────────────────────────────────────────────────────
RemoteAccess recognizes certain characters embedded in your
modem initialise strings, and converts them to special
functions. The supported characters are:
^ Raise DTR, modem will answer the phone.
v Lower DTR, disconnect if connected.
~ Wait for 1/4 of a second before continuing
| Send a carriage-return [CR] to the modem
97
Questionnaire script language
────────────────────────────────────────────────────────────
Questionnaire script files are stored in the system
directory and have the extension .Q-A. Each file is plain
ASCII, and contains one command per line. The available
commands are listed below. Note that the command interpreter
is case-insensitive, so the command "Ask" could be entered
as "ASK" or "ask".
98
Ask <Len> <Var num>
-------------------
Example : Ask 15 3
Waits for the user to input a string that is up to 15
characters long, and stores the string in the variable <Var
num>. Valid values for <Len> are 1 to 255. <Var num> may be
any number between 1 and 20.
Capitalise <ON|OFF>
-------------------
Example : Capitalise ON
Turns on or off auto-input prompt capitalisation.
ChangeColor <Foreground> <Background>
-------------------------------------
Example : ChangeColor 7 1
Changes the colour of the text if the user has ANSI graphics
enabled. Valid colours are:
<Foreground> <Background>
------------ ------------
0 Black 0 Black
1 Blue 1 Blue
2 Green 2 Green
3 Cyan 3 Cyan
4 Red 4 Red
5 Magenta 5 Magenta
6 Brown 6 Brown
7 Light Grey 7 Light Grey
8 Dark Grey
9 Light Blue
10 Light Green
11 Light Cyan
12 Light Red
13 Light Magenta
14 Yellow
15 White
ClearScreen
-----------
Example : ClearScreen
Clears the user's screen if he/she has enabled screen
clearing.
99
Display "<Text>"
----------------
Example : Display "Please answer ALL questions|"
Displays the specified text on the screen. The vertical bar
is translated to a line-feed and carriage return. If this
bar is ommitted, any following text starts at the next
character on the same line.
DisplayFile <1-8 character file name>
-------------------------------------
Example : DisplayFile BBSRULES
Causes a text file to be displayed in the same way as a menu
type 5 would be displayed. The text file must be in the text
file directory, and have the extension .ASC/.ANS.
EndIf
-----
Example : EndIf
Signifies the end of an IF statement.
If <Var num> = "<String>"
-------------------------
Example : If 5 = "Perth"
The IF command compares the contents of the specified
variable number with <String>. If the two do not match, then
all following lines are skipped until an ENDIF statement is
encountered.
Exec <commandline>
------------------
Example : Exec C:\RA\NEWMAIL.EXE *B
Executes a program in a DOS shell. All command-line
parameters valid in a menu type 7 command may be used.
100
GetChoice <Valid choices> <Var num>
-----------------------------------
Example : GetChoice YN 2
Waits for the user to enter one of the characters in <Valid
choices>, and stores the response in the variable <Var num>.
ListAnswer <Var num>
--------------------
Example : ListAnswer 5
Displays (to the screen) the contents of the variable <Var
num> followed by a CR/LF.
MenuCmnd <Num> <Data>
---------------------
Example : MenuCmnd 27 60 /T=Andrew_Milner
Executes a menu command. Simply specify the command number
followed by the contents of the optional data field. Note
that menu navigation commands (GOTO, GOSUB, RETURN etc) may
not be used.
OutputAnswer "<Descriptor>" <Var num>
-------------------------------------
Example : OutputAnswer "Hobbies : " 6
Outputs <Descriptor> followed by the contents of the
variable <Var num> to the questionnaire answer file. The
answer file is given the same name as the questionnaire file
but has an extension of .ASW.
PostInfo
--------
Example : PostInfo
Outputs the user's name and some other information to the
answer file.
101
Quit
----
Example : Quit
Terminates the questionnaire and returns to the BBS.
SetFlag <Flag set><Flag number> <ON|OFF>
----------------------------------------
Example : SetFlag C3 OFF
Turns on or off the specified user flag. <Flag set> is "A",
"B", "C" or "D", and <Flag number> is a number between one
and eight.
SetSecurity <Security level>
----------------------------
Example : SetSecurity 10
Simply sets the user's security level to the number
specified. The level may be any number from 1 to 64,000.
WaitEnter
---------
Example : WaitEnter
Waits for the user to press [ENTER].
102
Terminal emulations
────────────────────────────────────────────────────────────
A terminal emulation is the method that RemoteAccess uses to
communicate with the user's software. The most basic of
these is straight ASCII. The ASCII terminal emulation can
only display normally visible characters plus a few others,
such as backspace, linefeed and clearscreen.
RemoteAccess supports two additional emulations - ANSI and
AVATAR. ANSI is currently the most popular terminal
emulation in the bulletin board world; it has the capability
to change text colour, cursor position, and can do simple
animations. Some implementations of ANSI can even play
simple tunes at the user's end. ANSI does have some
drawbacks; each special control code is several characters
long. To change the text colour for example, requires a
control code of up to 8 characters. These lengthy codes can
severely slow the user's display, and for this reason the
usefulness of ANSI at speeds of 1200 baud and lower is
limited.
AVATAR, on the other hand, uses control codes that are
typically a quarter to a third of the length of their ANSI
equivalents, making it usable at lower speeds. Not only
that, but AVATAR has much more advanced screen control,
making possible relatively complex animations and screen
displays. AVATAR is a newcomer - there are comparatively few
terminal programs that support it, even fewer that support
it properly. At this time there are no utilities for
creating AVATAR screens. You can however convert your ANSI
screens to AVATAR with the supplied utility.
RemoteAccess uses AVATAR level 0+ (AVT/0+). The only
terminal programs which have been tested successfully with
AVT/0+ are Joaquim Homrighausen's FrontDoor and Adam
Stanislav's TinyTerm. If you make use of AVT/0+ you should
make it clear to your users that they should be using one of
these two, until more terminal programs implement AVATAR
support.
103
Text file naming conventions
────────────────────────────────────────────────────────────
RemoteAccess displays text files at specific points and in
response to specific events. The EXTERNAL SUPPORT FILES
section details all these text files. Files that have the
.A?? extension may be displayed in any one of three
"flavours":
.ASC : ASCII only, no special control codes
.ANS : ANSI, should only contain text and ANSI codes
.AVT : AVATAR, may contain text and AVATAR codes.
If a user has both ANSI and AVATAR enabled, RemoteAccess
will search first for a .AVT file, and if unsuccessful will
then try .ANS and then .ASC. If only ANSI *or* AVATAR is
selected and the preferred file type isn't available, the
.ASC version will be displayed.
104
Interactive EMSI
────────────────────────────────────────────────────────────
Interactive EMSI (IEMSI) is a protocol which can be used by
communications software to establish certain parameters for
an interactive session, for example a user logging on to a
bulletin board. The only software to support IEMSI at this
time is RemoteAccess 1.00 and FrontDoor 2.01.
From within the FrontDoor setup program, the user can define
a number of user "profiles", each of which includes a user
name, handle, password, telephone number, location etc. When
IEMSI is enabled from within the terminal and the user calls
a RemoteAccess BBS, the user's information is sent to the
BBS automatically.
This makes it possible for a user (the "client") to log on
to a BBS (the "server") without even touching the keyboard.
FrontDoor and RemoteAccess will automatically exchange
information such as software name and version number, screen
parameters and local time.
One useful feature is the ability of the server to
temporarily modify the user's display parameters for the
current session only. For example, normally when a user
calls a particular BBS he/she might use 25 line mode
locally, so the "screenlength" field in his/her record is
set to 25 accordingly. However, on one occasion he/she
activates the FrontDoor terminal in 50 line mode.
RemoteAccess will recognise this and set the screen length
to 50 for the current session only, restoring it to 25 when
the user disconnects. In addition, RemoteAccess will
automatically activate whatever terminal emulations both it
and the client supports.
To see if a user is connected in IEMSI mode to your BBS,
press F7. If IEMSI is active, RemoteAccess will display the
relevant information about the client's system on the status
bar. At the right hand end of the status bar the user's
request flags are displayed. A request flag is an option
that the user asked for. RemoteAccess currently supports
these request flags:
CLR : Clear screen codes
NEWS : Display the NEWS.A?? file
MAIL : Check for new mail
FILE : Check for new files
HOT : Use hot-keys
HUSH : Activate "do not disturb"
FSED : Use the full screen message editor
105
BATCH FILE EXAMPLES
────────────────────────────────────────────────────────────
These examples are not usable in their presented form. They
are provided as a starting point for your own batch files:
Using RemoteAccess stand-alone (ie. without a mailer)
-----------------------------------------------------
:START
Cd \RA
REM Run the main program:
RA -E20
REM User logged off, cycle back:
if errorlevel 20 goto START
REM RemoteAccess exits to the batchfile with errorlevel 7
REM once a night:
if errorlevel 7 goto CLEAN
if errorlevel 3 goto START
REM An errorlevel of 1 or 2 means a fatal error, an
REM errorlevel of 0 means that ESCape was pressed while
REM in "wait for call" mode - so we quit:
goto END
:CLEAN
REM Do nightly message and user maintenance with RAUSER
and RAMSG
goto START
:END
echo RemoteAccess HQ Line 1 Down.
NOTE : Unlike some other BBS packages, RemoteAccess will
ALWAYS exit back to DOS (or your batch file) after a caller
logs off. This means that you can only run in stand-alone
mode with a batch file that will recycle back to restart the
main program.
106
Using RemoteAccess with a mailer (FrontDoor or BinkleyTerm)
(using either TosScan or Echogen to process mail)
-------------------------------------------------
:START
cd \RA
REM Run the main program and run the mailer in a "shell".
REM The *M tells RemoteAccess to swap out of memory
REM before running the mailer.
REM Either FrontDoor : RA -m\FD\FD.EXE*M -E20
REM or BinkleyTerm : RA -m\BT\BT.EXE*M -E20
REM Any errorlevels that RemoteAccess does not understand
REM it passes back to the batchfile:
if errorlevel 150 goto CLEAN
if errorlevel 99 goto UNPACK
if errorlevel 20 goto START
if errorlevel 10 goto END
if errorlevel 5 goto NET&ECHO
if errorlevel 4 goto ECHO
if errorlevel 3 goto NET
goto END
:CLEAN
REM Do your nightly maintenance here. In this example
REM the mailer is set to exit at errorlevel 150 nightly.
:UNPACK
REM Toss incoming mail
REM Either : TOSSCAN toss
REM or : ECHOGEN -A -P -T -U
goto START
:NET&ECHO
REM Net and EchoMail needs to be exported from the
REM message base.
REM Either : TSUTIL export
REM or : MAILSCAN
:ECHO
REM Export EchoMail.
REM Either : TOSSCAN scan
REM or : ECHOGEN -A -E -P
goto START
:NET
REM Only export NetMail
REM Either : TSUTIL export
REM or : MAILSCAN
goto START
:END
REM Some fatal error occurred.
echo RemoteAccess HQ Line 2 Down.
107
* The Echogen command-line switches shown assume a FrontDoor
environment.
Note that the particular command-line switches for all of
these utilities (BinkleyTerm, FrontDoor, TosScan or
Echogen) will vary according to your set up. All of these
programs are supplied with documentation which will provide
you with this information. It is stressed again that these
examples are only intended to give you a starting point for
creating your own batch files.
108